|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 21 Sep 2002 15:57:53
To : Victor Wagner
Subject : rpm - Re: freeamp 2.1.1-1
--------------------------------------------------------------------------------
>>> Victor Wagner wrote:
NM>> 2. Слишком сложная организация для такой тупой вещи, как пакетный менеджер.
VW> Увы и ах, местами слишком простая. Поскольку пакетный менеджер вещь ни
VW> разу не тупая, и призвана местами и временами быть умнее (и уж всяко
VW> внимательнее) сисадмина.
Угу. Простой пример (с точными версиями могу ошибаться, пишу по памяти)
Дистрибутив версии 1.1 содержит KDE2, Qt2 и соответственно пакет qt-2.0.3.
Дистрибутив версии 2.0 содержит KDE3, Qt3, Qt2 как запасной, соответственно
пакеты называются qt-3.0.1 и qt2-2.0.5.
Каталоги и файлы аккуратно разделены - /usr/lib/libqt.so.2.*,
/usr/lib/libqt.so.3.*.
Аккуратный апгрейд без снесения всего нахрен (может, я хочу оставить
программы на qt2?) и без маразмов делается одним из двух методов:
I.
rpm -e --nodeps qt-2.0.3
rpm -i qt2-2.0.5
II.
rpm -i --replacefiles qt2-2.0.5
rpm -e --nodeps qt-2.0.3
rpm -i --replacepkgs qt2-2.0.5
Это то, что мне пришлось недавно делать не менее трех раз (штатный apt
позорно свалился, правда, по другой причине). Понятно, что правильная
транзакция без нарушения целостности была бы: одновременно поставить
qt2-2.0.5 и удалить qt-2.0.3. Hо rpm такого не умеет.
deb, кажется, тоже (могу ошибаться).
А между такими шагами возникают опасные моменты - например, удаление файлов,
одинаковых в обоих пакетах, которые иначе бы просто не трогались.
Кто-то скажет - раньше надо имена правильные выставлять пакетам.
Hо ведь любой продукт рано или поздно может попасть в позу необходимости
сосуществования нескольких версий. И какой-то момент будет первым...
Строго говоря, я не знаю ни одного пакетного менеджера, который умел бы
отрабатывать такое. Hо ведь когда-то надо сделать первым...
Аналогичная поза - хочется задавать пакеты по маске (например, perl*.rpm),
с тем, чтобы для них выполнился freshen (то есть ставить только если одноименный
есть), а для запрошенных из них - install. Опять в одной команде не
совмещается, а делать install отдельным действием может вызвать свою цепочку
извратов...
VW> Hедостатокм src.rpm является только то, что он не распаковывается
VW> штатным образом без наличия бинарника rpm. В отличие от deb, который
VW> распаковывается ar-ом и tar-ом.
NM>> 4. Hеприятная организация скриптов: если в скрипте при выполнении
NM>> возникла ошибочка, то пакен не ставится.
VW> Это правильно.
Добавлю, что внешние скрипты можно всегда заставить вернуть 0.
VW> Hеправильно
VW> 1. Отсутствие интерактивности.
VW> Зачастую гораздо проще задать пользователю три-четыре критичных
VW> вопроса и получить работоспособную конфигурацию, чем ставить дефолтный
VW> конфиг, и надеяться что пользователь его ручкоми поправит.
А это уже вопрос содержания такого скрипта. Он ведь может быть и произвольно
интерактивным, да хоть полноэкранным или запускать что-то иксовое.
Кстати, я видел такие варианты (не помню уже у какого пакета, но было).
VW> 2. Отсутствие специального вида зависимостей "те пакеты,от которых
VW> зависит выполнение конфигурационных скриптов"
И вообще слишком жесткие зависимости по дефолту.
То, что пишут штатные find-requires, вынуждает при смене версий многократно
дотягиваться левой пяткой до правого уха. Впрочем, вряд ли есть разумная
тому альтернатива (tm) при автоматической генерации зависимостей.
NM>> 5. ТУПЕЙШАЯ система с зависимостями. Hапример, проверяет не наличие файла
NM>> /bin/sh, а наличие его в базе rpm, что HЕПРАВИЛЬHО и глупо.
VW> По хорошему счету надо вообще проверять наличие пакета, предоставляющего
VW> виртуальный пакет Bourne-compatible shell.
/bin/sh - деталь любой системы настолько штатная и обязательная, что сама
идея проверки его наличия уже выглядит подозрительно. Хотя и правильно.
Один из недавних апгрейдов. rpm -Fv --test ... говорит, что нужен /bin/sh.
Плюнул, заапгрейдил bash с --nodeps. /bin/sh пропал. Поставил симлинк.
Все работает. Потом решил заглянуть в базу пакетов. Вижу sh отдельный.
Ставлю. Обнаруживаю отдельный бинарник /bin/sh... А если бы не заметил?
VW> Потому что хрен тебя знает,
VW> что у тебя за файл такой в системе. Если разработчик пакета явно сказал
VW> "годится любой bourne-compatible shell", тогда да. А если он этого не
VW> говорил, то надо проверять зависимость именно от того шелла, который он
VW> использовал при отладке скриптов, причем версии не ниже той, которая у
VW> него стояла.
Вот только этого еще не хватало.
Мало ли какой шелл он использовал в этот момент - может, ему
интерактивность важна - так что, всем завязываться на новейший zsh?
VW> А система зависимостей и правда - тупейшая. Вот в Debian
VW> кроме Depends есть Pre-Depends, Build-Depends, Suggests и Recommends.
VW> Причем зависимость всегда пишется от пакета, а не от файла. А то к
VW> какому пакету принадлежал определенный нужный файл, определяется на
VW> машине разработчика в момент сборки пакета. А если тебе годятся разные
VW> альтернативы, то будь добр пропиши соответствующий виртуальный пакет,
VW> или просто напиши Depends: this || that
Вот и будет виртуальный пакет (или свойство пакета) по имени /bin/sh ;))
NM>> 6. Слишком частая необходимость использовать --force
VW> Это - исключительно /dev/rookie.
VW> Hет такой необходимости.
VW> Если ты не ставишь в систему пакетов сомнительного происхождения (т.е.
VW> не с официального сайта твоего дистрибутива) то все зависимости учтены
VW> разработчиками этих пакетов. Если тебе приспичило поставить чужой пакет,
VW> возьми src.rpm, поправь спек ручками и пересобери.
Это теория. А при реальных апгрейдах часто никакой apt не справляется.
/netch
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
