LINUX.ORG.RU

Ответ на: комментарий от bbk123

Как тут уже говорилось DEB привязан к дистрибутиву. Предположим я используют Mint и предположим в одном из пакетов, полученном от Debian, найдена проблема. В этом случае исправление должно вначале появиться в Debian. Затем оно перекочует в Ubuntu и лишь после этого станет доступным в Mint.

То, что Debian --> Ubuntu --> Mint по сути используют одну и туже пакетную базу (плюс небольшие довески) говорилось и раньше, причём неоднократно.

Это просто один пример. Ты меняешь свою точку зрения на противоположную постоянно. Как скажи мне соотносятся эти два твоих утверждения в одном треде? Если пакетная база одна, что за чушь ты тогда писал несколькими постами выше?

mbivanyuk ★★★★★
()
Ответ на: комментарий от mbivanyuk

В каком месте процитированное тобой тебе не понятно или где ты там нашёл противоречия?

Если тебе что-то непонятно, то лучше спросить, а не разбрасываться обвинениями в чуше. Иначе чушью могут оказаться твои собственные заявления.

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от bbk123

Без обид, тебе уже ответили, что ерунду сказал ты

Где? Покажи мне этот пост. Пока тебе объясняют то же что пытался объяснить и я. Например господин Nxx совершенно справедливо тебе ответил - «Это один и тот же дистрибутив, но под разными брендами. Ubuntu не может взять и начать развиваться независимо от Дебиана. даже если ты им предложишь патч, они тебя пошлют в Дебиан.»

Как тут уже говорилось DEB привязан к дистрибутиву

Ещё раз повторяю, deb-пакеты относительно легко ставятся в любом deb-based. Никакой привязки к разным дистрибутивам нет, все они привязаны только к Debian. В отличие от rpm.

mbivanyuk ★★★★★
()
Ответ на: комментарий от Nxx

Ну да, если пакаджеры совершенны и не ошибаются, то... .rpm просто не установится в «третью» систему. Но реальный мир такой реальный.

tailgunner ★★★★★
()
Ответ на: комментарий от bbk123

лучше спросить

Спрашиваю - если после того, как тебе десять раз объяснили ты не хочешь понять или хотя бы воспользоваться поиском по ЛОРу, где эта тема неоднократно обсуждалась ты тролль или просто тебе делать нечего? ))

mbivanyuk ★★★★★
()
Ответ на: комментарий от bbk123

Так как же rpm находит правильный libfoo.rpm, который нужен для prog.rpm?

Находит пакетный менеджер, например, zypper.

И что если этот libfoo.so.1 есть сразу в нескольких rpm-ах, обратно совместимых между собой?

Зависит от настроек, ставит более новую версию или спрашивает пользователя. Учитывает приоритет репозиториев.

Nxx ★★★★★
()
Ответ на: комментарий от tailgunner

Ну да, если пакаджеры совершенны и не ошибаются, то... .rpm просто не установится в «третью» систему. Но реальный мир такой реальный.

Это не зависит от пакаджеров. Зависимости в rpm прописываются автоматически.

Nxx ★★★★★
()
Ответ на: комментарий от mbivanyuk

Где? Покажи мне этот пост.

Arch-е подобные дистрибутивы на RPM (комментарий)

Пока тебе объясняют то же что пытался объяснить и я. Например господин Nxx совершенно справедливо тебе ответил - «Это один и тот же дистрибутив, но под разными брендами. Ubuntu не может взять и начать развиваться независимо от Дебиана. даже если ты им предложишь патч, они тебя пошлют в Дебиан.»

Ты не поверишь, но именно об этом говорил и я. Debian --> Ubuntu --> Mint по сути используют одну и туже пакетную базу (плюс небольшие довески) - это означает, что фактически это один дистрибутив с разными довесками.

Ещё раз повторяю, deb-пакеты относительно легко ставятся в любом deb-based.

В этом высказывании есть лишь одна проблема. Есть лишь один deb-based дистрибутив - тот самый Debian --> Ubuntu --> Mint.

Больше пережовывать я не могу, прости. Если до сих пор не понятно о чём я говорю, значит мы говорим на разных языках и никогда не поймём друг друга.

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от mbivanyuk

Никакой привязки к разным дистрибутивам нет, все они привязаны только к Debian.

А кто тут говорил о привязке к РАЗНЫМ дистрибутивам? Они все привязаны к одному дистрибутиву.

Nxx ★★★★★
()
Ответ на: комментарий от Nxx

Зависимости в rpm прописываются автоматически.

Автоматически там прописываются soname. Зависимость soname от опций конфигурации зависит от пакаджера.

tailgunner ★★★★★
()
Ответ на: комментарий от Nxx

Находит пакетный менеджер, например, zypper.

Тоесть одной лишь программы rpm (как во времена RedHat 5.x) уже недостаточно? А что делает пакетный менеджер? Ищет в базе данных репозитория, как я предпроложил выше?

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

Зависимость soname от опций конфигурации зависит от пакаджера.

Еще раз. Если в soname меняется версия ABI, то она прописывается в зависимость наряду с soname, автоматически.

Nxx ★★★★★
()
Ответ на: комментарий от bbk123

Тоесть одной лишь программы rpm (как во времена RedHat 5.x) уже недостаточно?

rpm просто скажет, что зависимости не удовлетворены и пакет не поставит.

А что делает пакетный менеджер? Ищет в базе данных репозитория, как я предпроложил выше?

Да.

Причем, пакетный менеджер может быть apt, который и в дебиане используется.

Nxx ★★★★★
()
Последнее исправление: Nxx (всего исправлений: 1)
Ответ на: комментарий от Nxx

Но я помню, как во временя RedHat 5.x обходились одной лишь программой rpm. Как же so резолвились в rpm в те времена?

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от bbk123

В RedHat раньше использовали программу up2date, потом заменили её yum'ом.

Nxx ★★★★★
()
Ответ на: комментарий от bbk123

голый rpm не предоставляет возможностей автоматического разрешения зависимостей.

Nxx ★★★★★
()
Ответ на: комментарий от Nxx

Если ABI не меняется, совместимость не страдает.

Итак: с чего бы soname менялся в зависимости от опций confugure? Кто это гарантирует?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

опции configure бывают разные. Например, использовать аппаратное ускорение или нет. Использовать внешнюю библиотеку или нет и т.д. далеко не факт, что они влияют на ABI

Nxx ★★★★★
()
Ответ на: комментарий от bbk123

Как же so резолвились в rpm в те времена?

Тогда нужно было резолвить их вручную (но это нетрудно). up2date это умел, наверное, но, поскольку это был клиент к огороженному сервису Redhat, им мало кто пользовался. Позднее запилили yum и apt-get для RPM.

tailgunner ★★★★★
()
Ответ на: комментарий от Nxx

Ладно, забьем. Ты так упорно уходишь от ответа, что мне просто лень за тобой гоняться.

tailgunner ★★★★★
()

Решил таки пересилить себя и попробовать второй раз водрузить openSuSE на свой компьютер. Первая попытка частично описана тут:

Arch-е подобные дистрибутивы на RPM (комментарий)

На этот раз я таки дотерпел до конца и вот сейчас пишу из openSuSE 12.3. Опыт чисто мазохистский, так и хочется гавкнуть что нибудь по немецки, которого я не знаю.

Перед установкой я настроил сеть со статическим адресом и поменял HTTP адрес на местное зеркало. Затем запустил инсталяцию. Я выбрал тип десктопного окружения XFCE. Выбрать конкретные покеты инсталлятор мне не дал или спрятал глубого в прямой кишке. Короче началась старая эпопея с выкачиванием 2.5 гиг rpm-ов. Во время инсталляции периодически шуршал дисковод. Зачем он кому-то понадобился не понятно. Наконец все 2.5 гига rpm-ов были скачены и установлены. Инсталятор ушёл в reboot. Поднявшись свежий openSuSE продолжил инсталляцию и опять зачем-то пошуршав дисководом предложил установить апдейты. Я согласился и выбрал все предложенные мне апдейты. Тут оказалось, что он не может подключиться к официальному серверу openSuSE. Оказалось, что инсталлятор просто забыл прописать DNS, которым сам же пользовался до ребута. Я руками добавил nameserver 192.168.1.1 в /etc/resolv.conf и тут опять началась эпопея с шуршанием дисковода и выкачиванием тучи, на этот раз drpm-ов (дельт к rpm-ам). При этом двух drpm-ов на официальном сайте openSuSE (на этот раз использовался именно он, а не зеркало) не оказалось. Вот этих:

gpg2-2.0.19-5.1.1_5.4.1.i586.drpm
MozillaThunderbird-17.0.3_17.0.8-61.21.1.i586.drpm

Оба раза я нажимал на Ignore и обновление продолжалось. Затем инсталлятор запросил ещё один ребут. Я согласился, но во время shutdown-а система тупо зависла и ни на что не реагировала. Пришлось жать на reset на системнике. Ok, загрузился снова и снова попал в инсталлятор, который радостно сообщил, что есть новые апдейты: unrar и ещё более новые, чем выше, версии gpg2 и MozillaThunderbird. Я решил, что лучше всё таки дотерпеть и еле сдерживая блевотные инстинкты на этот немецкий инсталлятор всё таки довёл установку системы до конца. Короче война и немцы, а этот ваш openSuSE - это сплошной гитлер-капут.

Инсталлятор там реализован в YaST2, которым нужно потом пользоваться всю жизнь. Если инсталлятор такой глючный, с неудобным и неочевидным интерфейсом, то и весь YaST2 такой же. Кроме того в XFCE система явно тормозит. По крайней мере ни в Fedora, ни в Arch такого подтормаживания в XFCE не ощущалось.

bbk123 ★★★★★
() автор топика
Последнее исправление: bbk123 (всего исправлений: 2)
Ответ на: комментарий от bbk123

Одно лишь радует, что из коробки установились нормальные фонты и вебсайты сразу выглядят по-человечески.

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от bbk123

В стандартном репозитории пакетов не оказалось audacious. Пришлось добавлять дополнительный репозиторий, вот этот ftp://ftp.uni-erlangen.de/pub/mirrors/packman/suse/12.3/ Там audacious нашёлся и я даже начал его устанавливать через Software Manager (YaST). Но посреди всего этот Software Manager тупо упал. Тоесть как я и говорил, этот ваш YaST - глючное дерьмо гитлера.

bbk123 ★★★★★
() автор топика
Последнее исправление: bbk123 (всего исправлений: 1)
Ответ на: комментарий от bbk123

Оказалось, что он не падает, а просто беззвучно завершает работу в конце установки новых пакетов. Идиотизм. У разработчиков этого поделия нет ни малейшего понятия о user experience.

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от bbk123
Absolute path to 'ss' is '/usr/sbin/ss', so running it may require superuser privileges (eg. root).


А это что за фигня, травма второй мировой войны? Эта программа прекрасно работает из под обычного пользователя (командой /usr/sbin/ss). Какого хрена шелл (или кто-то другой?) вывел это предупреждение и какое отношение /usr/sbin имеет к привилегиям рута?

bbk123 ★★★★★
() автор топика
Последнее исправление: bbk123 (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Вы смотрите репортаж из горящего немецкого танка, оставайтесь с нами!

Упал под стол!

Снесу это openSuSE глюкало как только Fedora исправит регрессию в skge.

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

Нет, люди в основном с Европы. Хотя наверно в процентном соотношении немцев действительно большинство.

dinn ★★★★★
()
Ответ на: комментарий от bbk123

У меня этот дистр вообще поставился только с третьего раза - всеникак загрузчик не хотел работать. А процесс выбора раздела при этом напомнил об анакондовской шизофрении.

Ну поставился и ладно бы, так яст каждые три минуты в кедах орето какой-то ошибке, дрова видеокарты вешают иксы, а команда выключения не делает ничего кроме парковки головок винта.

В очередной раз разочаровался в юзер френдли дистрибутивах и сбежал облатно на арч

anonymous
()
Ответ на: комментарий от anonymous

В очередной раз разочаровался в юзер френдли дистрибутивах и сбежал облатно на арч

Был я и там. Арч является дистрибутивом лишь формально. На самом деле это просто свалка софта из апстрима. Причём софт иногда выпускается после тестирования с известными критическими багами. А потом они тупо ждут когда на апстриме закомитят патч. Практически тот же патч, проверенный их же арчевым тестировщиком, они игнорируют ибо не апстрим. Короче дети (большинство 80-х годов рождения), а иногда и неадекватные (из опыта общения с ними).

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от bbk123

SuSE и этот их YaST

А разговор об openSUSE, а YaST сейчас по большей части разрабатывается ребятами из Чехии, насколько помню.

dinn ★★★★★
()
Ответ на: комментарий от dinn

А разговор об openSUSE, а YaST сейчас по большей части разрабатывается ребятами из Чехии, насколько помню.

Я тоже об openSUSE, в котором тоже YaST. А чехи, судя по всему, не разрабатывают, а лишь поддерживают старое строение этого гестапо.

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от bbk123

А чехи, судя по всему, не разрабатывают, а лишь поддерживают старое строение этого гестапо.

В openSUSE 13.1 будет новый YaST на ruby.

dinn ★★★★★
()
Ответ на: комментарий от bbk123

Короче дети (большинство 80-х годов рождения)

Очень весомый аргумент.

иногда и неадекватные

Это от возраста не зависит.

dinn ★★★★★
()
Ответ на: комментарий от dinn

В openSUSE 13.1 будет новый YaST на ruby.

Предлагаешь попробовать бету? Они его таки переписали по-человечески или это тот же YaST но на ruby?

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от dinn

Очень весомый аргумент.

Это первое, на что я обратил внимание, попав на список этих так называемых разработчиков.

Это от возраста не зависит.

Возможно, но в данном случае совпало.

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от bbk123

Предлагаешь попробовать бету?

Нет, в лучшем случае когда RC пойдут, пока слишком много всего не доделано.

Они его таки переписали по-человечески или это тот же YaST но на ruby?

В идеале тот же YaST, только на ruby (поскольку текущий язык создан только для YAST) и без глюков.

dinn ★★★★★
()
Ответ на: комментарий от dinn

Нет, в лучшем случае когда RC пойдут, пока слишком много всего не доделано.

Я не против помочь разработчикам. Но только если у их софта есть шанс стать нормальным.

В идеале тот же YaST, только на ruby (поскольку текущий язык создан только для YAST) и без глюков.

И зачем оно такое кому-то надо? В чём смысл переписывания на Ruby?

bbk123 ★★★★★
() автор топика
Последнее исправление: bbk123 (всего исправлений: 1)
Ответ на: комментарий от bbk123

В чём смысл переписывания на Ruby?

Он написан на созданном только для него языке - YCP, а такое поддерживать и тем более привлекать новых разработчиков сложно.

dinn ★★★★★
()
Ответ на: комментарий от bbk123

Он и в текущий момент очень неплох, во всяком случае версия для qt. А вы просто невнимательно смотрели во время установки, многого можно было избежать.

dinn ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.