Arch-е подобные дистрибутивы на RPM

Мы как бы помягче выразиться, не всегда доверяем аргументам этого знатока.

Точно такой же аргумент, но другими словами, озвучил Nxx. Ему вы (кстати кто это вы?) тоже не доверяете?

Тебе не зря советуют openSUSE Tumbleweed.

Так чем же оно отличается от Федоры?

В целом поддерживаю, но и пользователям Fedora они тоже не нужны.

Осиляторство кривого софта не является моей целью ибо пользы от этого никакой.

Ну хорошо, поставил я таки Федору без grub2 и затем установил его вручную (ибо федорасты решили, что без mbr gap они никого не поддерживают). А там уже все последнии обновления, включая последнее ядро 3.11.1 с известной регрессией в skge. Тоесть Федора у меня уже есть, а сети в ней нет. Кстати, в Arch-е уже успели это исправить, хотя тоже провозились слишком долго. Федорасы исправили вчера, а нового RPM-а пока нет:

https://bugzilla.redhat.com/show_bug.cgi?id=1008323

Ну не знаю, попробуй PLD:

https://www.pld-linux.org/about

Основан на RPM, роллинг (хотя, может, и не роллинг - релиз был в сентябре).

Я на него уже натыкался. Так и не понял где скачать ISO к версии 3.0, с которой он и стал роллинг.

А свое мнение? Неужели несуществующий объективно идеальный пакетный менеджер настолько же важен и принципиален, как обои в BolgenOS? Или как его там..

А свое мнение?

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

Неужели несуществующий объективно идеальный пакетный менеджер настолько же важен и принципиален

Да, поскольку зависимость программы от всей системы для меня является дикостью. Предположим, что у меня стоит последняя Ubuntu LTS. Там используется gtk 3.6.x. Это значит, что я не могу параллельно установить gtk 3.8.x или 3.10.x и программы, которым нужна именно эта версия gtk.

Тебе не зря советуют openSUSE Tumbleweed.

Так чем же оно отличается от Федоры?

Тем, что к 13-му релизу Fedora была изменена политика обновлений.
А Tumbleweed создан с целью обеспечения непрерывного обновления версий openSUSE, содержащих последние стабильные версии ПО, вместо периодических циклических выпусков.

Tumbleweed
How to Upgrade openSUSE 12.x to Tumbleweed
HowTo Backup and Restore the Tumbleweed Root/System Partition Quickly & Simply

Обновление версий и наращивание функциональности программ в пакетах в рамках уже выпущенного релиза запрещено.

Это из той статьи на OpenNet. Вот я поставил 19-ю Федору по сети и получил последнюю версию ядра. 3.11.1 вместо 3.9.5. Они опять, что ли, изменили политику обновлений и стали роллинг?

Кроме того есть Fedora Rawhide.

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

Тогда какая тебе разница, dpkg или RPM? Я еще понимаю, если поддерживаешь десяток свои пакетов, но обычному пользователю - один черт что RPM, что dpkg, он в любом случае пользуется apt-get/yum/zypper.

Предположим, что у меня стоит последняя Ubuntu LTS. Там используется gtk 3.6.x. Это значит, что я не могу параллельно установить gtk 3.8.x или 3.10.x

Интересно, где такое можно?

Интересно, где такое можно?

Если я правильно понял, это возможно в RPM.

Тогда какая тебе разница, dpkg или RPM? Я еще понимаю, если поддерживаешь десяток свои пакетов, но обычному пользователю - один черт что RPM, что dpkg, он в любом случае пользуется apt-get/yum/zypper.

Как тут уже говорилось DEB привязан к дистрибутиву. Предположим я используют Mint и предположим в одном из пакетов, полученном от Debian, найдена проблема. В этом случае исправление должно вначале появиться в Debian. Затем оно перекочует в Ubuntu и лишь после этого станет доступным в Mint. А если завтра появится новый дистрибутив, использующий DEB но не основанный на Debian, то появится ещё один репозиторий deb пакетов, практически полностью несовместимый с Debian/Ubuntu/Mint. У RPM такого быть не может. Вот Oracle даёт JDK/JRE либо в tar.gz для убогих, либо в RPM для всех остальных. И этот RPM можно установить в любом дистрибутиве, использующем RPM.

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

У RPM такого быть не может

И этот RPM можно установить в любом дистрибутиве, использующем RPM

Слушай, без обид, зачем такую ерунду писать? Deb-пакеты из одного дистрибутива как раз относительно неплохо ставятся в другие deb-based дистрибутивы. А вот для rpm в этом отношении всё гораздо хуже. Версии rpm, spec-файлы и сами пакеты часто несовместимы между дистрибутивами. В результате rpm-пакет из одного дистрибутива зачастую нельзя поставить в другой rpm-based.

Интересно, где такое можно?

Если я правильно понял, это возможно в RPM.

Это теоретически возможно сделать на RPM, но это за его рамками. Я не знаю RPM-дистрибутивов, в которых это сделано.

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

.deb привязан к дистрибутиву не больше, чем .rpm.

У RPM такого быть не может.

Может и есть.

Вот Oracle даёт JDK/JRE либо в tar.gz для убогих, либо в RPM для всех остальных.

Кросс-дистрибутивые .rpm нужно специально делать (и так же можно делать кросс-дистрибутивные .deb).

Deb-пакеты из одного дистрибутива как раз относительно неплохо ставятся в другие deb-based дистрибутивы

Это один и тот же дистрибутив, но под разными брендами. Ubuntu не может взять и начать развиваться независимо от Дебиана. даже если ты им предложишь патч, они тебя пошлют в Дебиан.

Слушай, без обид, зачем такую ерунду писать?

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

Версии rpm, spec-файлы и сами пакеты часто несовместимы между дистрибутивами.

На сколько часто? Ещё раз привожу тот же пример Oracle даёт JDK/JRE в виде RPM. Есть ли какой-то RPM-based дистрибутив, в котором эти rpm-ы не установятся? Разумеется, если очень захотеть, можно отстрелить себе ногу. Но этот вариант совершенно неинтересен.

ну так что же решил ты себе ставить?

Кросс-дистрибутивые .rpm нужно специально делать (и так же можно делать кросс-дистрибутивные .deb).

Как именно их можно делать? Если deb не поддерживает зависимости по ABI, то там просто перечислены несовпадающие имена пакетов из разных дистрибутивов. А если завтра появится новый дистрибутив с третьим вариантом названия того же пакета, то этот deb к нему не подойдёт. Я правильно думаю?

ну так что же решил ты себе ставить?

Ещё не решил. Попробовал Debian, но там пока сеть не работает:
Arch-е подобные дистрибутивы на RPM (комментарий)
Может быть на днях исправят, поставлю заново.

Предположим, что у меня стоит последняя Ubuntu LTS. Там используется gtk 3.6.x. Это значит, что я не могу параллельно установить gtk 3.8.x или 3.10.x и программы, которым нужна именно эта версия gtk.

Не совсем так.

rpm:

вариант 1. gtk 3.10 обратно совместима с gtk 3.6 по ABI.

Тогда ты устанавливаешь gtk 3.10 и все программы работают

вариант 2. gtk 3.10 обратно не совместима с gtk 3.6. В этом случае тебе придется выбирать между программами, которым нужно gtk 3.6 и теми, которым нужно gtk 3.10. Те программы, которые совместимы с обеими библиотеками, обновлять не потребуется.

deb:

вариант 1. gtk 3.10 обратно совместима с gtk 3.6 по ABI.

В этом случае имеем два подварианта

вариант 1а. (более вероятный)

В программах зависимость от gtk прописана как версия <= 3.6. В этом случае тебе придется обновлять всю систему до программ, совместимых с gtk 3.10, иначе ты gtk 3.10 не установишь

вариант 1б. (менее вероятный)

В программах зависимость от gtk прописана без указания версии или как версия >= 3.6.

В этом случае ты обновишь gtk и все будет работать

вариант 2 gtk 3.10 обратно не совместима с gtk 3.6 по ABI.

В этом случае опять имеем два подварианта

вариант 2а. (более вероятный) В программах зависимость от gtk прописана как версия <= 3.6.

В этом случае тебе придется выбирать между программами, которым нужно gtk 3.6 и теми, которым нужно gtk 3.10, для новых программ придется обновить всю систему.

вариант 2б. (менее вероятный)

В программах зависимость от gtk прописана без указания версии или как версия >= 3.6.

В этом случае все старые программы просто ломаются и падают при запуске или во время работы. Пакетный менеджер ошибку не выдаёт.

А если завтра появится новый дистрибутив с третьим вариантом названия того же пакета, то этот deb к нему не подойдёт. Я правильно думаю?

Правильно.

Если новая версия библиотеки обратно не совместима со старой, то разве её so файл не будет иметь других цифорок в имени? И разве две версии этой библиотеки, в этом случае, не смогут ужиться в одной системе?

src.rpm-пакеты и spec-файлы обычно не совместимы.

бинарные пакеты обычно совместимы для дистрибутивов одного времени выпуска.

Исключение могут составлять пакеты, написанные на всяких экзотических интерпретируемых языках (то есть, те в которых исполняемые файлы - не бинарные). Иногда бывают проблемы с программами, написанными на питоне.

Если новая версия библиотеки обратно не совместима со старой, то разве её so файл не будет иметь других цифорок в имени?

Будет.

И разве две версии этой библиотеки, в этом случае, не смогут ужиться в одной системе?

В принципе, пакет можно назвать по-другому, и если там нет пересекающихся файлов, то оба пакета спокойно установятся параллельно и будут правильно удовлетворять зависимости программ, которые о переименовании пакетов не знали.

Так что, да, это возможно, и так часто делают.

Ситуация нексколько усложняется тем, что в пакетах обычно не один, а несколько so-файлов, но такой пакет всегда можно разбить на несколько.

Значит если gtk 3.6.x и 3.10.x не совместимы, то их таки можно установить параллельно в одну систему?

Я сейчас посмотрел зависимости этих пакетов. Теоретически, на openSUSE 12.3 ты сможешь обновить gtk 3.6 до gtk-3.9 из Factory.

При этом переставится (на более новую версию) только один пакет:

gtk3-branding-openSUSE

Все старые программы должны нормально работать с новой версией GTK, так что ставить библиотеки параллельно не понадобится.

На Дебиане такое, естественно, невозможно.

Это потому что в gtk существует обратная совместимость. Из-за этого мой пример с gtk иллюстрирует не самую худшую ситуацию. Но даже эта ситуация создаёт массу проблем в Debian-подобных системах.

В общем пока я придерживаюсь мнения, что RPM лучше. Кстати, что скажешь об RPM5?

Кросс-дистрибутивые .rpm нужно специально делать (и так же можно делать кросс-дистрибутивные .deb).

Как именно их можно делать?

Ориентироваться на общее подмножество библиотек и программ.

А если завтра появится новый дистрибутив с третьим вариантом названия того же пакета, то этот deb к нему не подойдёт. Я правильно думаю?

Правильно. А если завтра появится новый RPM-дистрибутив, в котором что-то, от чего зависит пакет, назовут по-другому, этот .rpm не подойдет.

На Дебиане такое, естественно, невозможно.

А ты точно понял вопрос, который тебе задали?

bbk123> установить параллельно в одну систему?

Правильно. А если завтра появится новый RPM-дистрибутив, в котором что-то, от чего зависит пакет, назовут по-другому, этот .rpm не подойдет.

Так ведь в RPM зависимости не по именам пакетов. Или я что-то не так понял?

Правильно. А если завтра появится новый RPM-дистрибутив, в котором что-то, от чего зависит пакет, назовут по-другому, этот .rpm не подойдет.

Так ведь в RPM зависимости не по именам пакетов

Зависимости по именам пакетов там тоже есть. Но гипотетическому дистрибутиву ничто не мешает переименовать и библиотеку (.so-файл).

Он там написал, что параллельно не надо, а можно обновить лишь gtk и старые программы продолжат работать за счёт обратной совместимости. И вот в Дебиан это якобы невозможно.

Но гипотетическому дистрибутиву ничто не мешает переименовать и библиотеку (.so-файл).

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

Он там написал, что параллельно не надо

То, что он написал, неважно - он RPM-тролль. Задача как формулируется?

С чего вдруг кто-то решит переименовывать so файлы?

С того же, с чего они стали переименовывать пакеты. Кроме того, разные опции configure могут дать один и тот же .so-файл с разными возможностями.

В общем пока я придерживаюсь мнения, что RPM лучше. Кстати, что скажешь об RPM5?

Ничего не скажу. Левый форк, не имеющий никаких серьезных преимуществ. Изначально был не совместим с LSB, потому что из него выпилили обратную совместимость (и преподносили это как достоинство), потом на это напоролась Мандрива, которая перешла на RPM5 и совместимость туда впилили обратно. Сейчас RPM5 стараниями Мандривы поддерживают в состоянии, совместимом с нормальным RPM, но это сложно и бессмысленно.

А если завтра появится новый RPM-дистрибутив, в котором что-то, от чего зависит пакет, назовут по-другому, этот .rpm не подойдет.

so-name не определяется политикой дистрибутива. И в Дебиане и в тарболе сонейм одинаковый. А зависимости в rpm прописаны на сонейм.

То, что он написал, неважно - он RPM-тролль.

Неужели такие бывают?

Задача как формулируется?

Можно ли установить две несовместимые между собой версии библиотеки. На это он сказал, что можно. Вот тут:

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

С того же, с чего они стали переименовывать пакеты.

Не переименовывать, а называть по своему. Речь шла о независимых друг от друга дистрибутивах. Вот в Arch-е ядро находится в пакете linux-xxx, в Федоре в пакете kernel-xxx, а в Debian в пакете linux-image-xxx.

Кроме того, разные опции configure могут дать один и тот же .so-файл с разными возможностями.

Это конечно аргумент. Но только зачем кому-то ограничивать эти возможности? И если в данном дистрибутиву отключили некую возможность X у некой библиотеки Y, без которой не работает программа Z, то эта программа вообще никогда там не заработает. Не важно, используешь ли ты DEB, RPM или даже pacman.

Значит если gtk 3.6.x и 3.10.x не совместимы, то их таки можно установить параллельно в одну систему?

Кслассический пример - KDE3 и KDE4.

Сейчас в openSUSE официально входят оба. Можно установить одновременно KDE3 и KDE4. Все программы как работали, так и работают. Можно установить две версии amarok, ktorrent и т.д. Можно даже установить kde3-программы из другого дистрибутива.

Никаких серьезных переделок КДЕ3 для совместимости с КДЕ4 не понадобилось. Было переименовано несколько пакетов (добавлен префикс kde3-), но на зависимостях это никак не сказалось.

В Debian это невозможно. Создатели Trinity (оторые используют Убунту) радикально его переделали. Пришлось переименовывать почти все программы. Разумеется, все зависимости оказались поломанными. В Trinity много просто поломанных зависимостей, таких, что программа будучи установленной не удаляется. Но даже если они все баги исправят, всё равно, старые qt3 и kde3 приложения не воспринимают Trinity за кде3 и ругаются на зависимости. Поэтому тот, кто использует Trinity ограничен только теми программами, которые входят в его состав.

Есть ли такие? Федору не предлагать

ТоварищЪ, ты же сам себе противоречишь!

А зависимости в rpm прописаны на сонейм.

А как по этим зависимостям находятся конкретные rpm пакеты?

Можно ли установить две несовместимые между собой версии библиотеки. На это он сказал, что можно. Вот тут:

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

С такими оговорками это возможно в любой системе.

Но только зачем кому-то ограничивать эти возможности?

А зачем в Gentoo USE-флаги? А зачем в .src.rpm with-опции?

А как по этим зависимостям находятся конкретные rpm пакеты?

В каждом пакете прописано, какие so-файлы там внутри. Можно и искусственно добавить любой символ в секцию «предоставляет».

Федору не предлагать

Тогда прости, ничего нет. Хотя есть еще PCLinuxOS, но это адский велосипед.

Кроме того, разные опции configure могут дать один и тот же .so-файл с разными возможностями.

Эти возможности не должны влиять на ABI. Иначе файл должен называться по-другому (с другой цифрой после точки). Иное - нарушение принципов POSIX.

С такими оговорками это возможно в любой системе.

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

В каждом пакете прописано, какие so-файлы там внутри.

Я не об этом.

Можно и искусственно добавить любой символ в секцию «предоставляет».

Тоесть добавить зависимость на имя пакета. Но это же тот же DEB. Или я что-то не так понял?

Эти возможности не должны влиять на ABI

Ч0рт. Даже не знаю, что сказать. «Такого быть не должно!» - а если оно есть?

Иное - нарушение принципов POSIX.

Напомни мне секцию POSIX, которую это нарушает.

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

WAT

Тоесть добавить зависимость на имя пакета. Но это же тот же DEB. Или я что-то не так понял?

Зависимости по именам пакетов в rpm используют редко. В основном, когда зависимость нужна не для линковки или вызова каких-то функций, а когда, например, пакет содержит данные или картинки или примеры программ какие-нибудь скрипты на интерпретируемом языке. Причем, всегда можно пакет переименовать без поломки зависимости, просто добавив старое имя в Provides.

Ч0рт. Даже не знаю, что сказать. «Такого быть не должно!» - а если оно есть?

Да, в некоторых случаях soname не меняется, но тогда версия ABI включается в зависимости. Также, как и зависимость от somane это включение происходит автоматически на основе информации линковщика.

Тогда в пакете будет прописано, какие версии ABI библиотека предоставляет.

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