|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 02 Jan 2003 18:06:48
To : Vladimir Bormotov
Subject : Re: rpm dependences in Linux distributions
--------------------------------------------------------------------------------
>>> Vladimir Bormotov wrote:
VN>> Hе-а. Я с ней сталкивался при _каждом_ апдейте любого дистрибутива в
VN>> пределах по крайней мере линии RH7 и последователей.
VB> примерно два раза в год.
Умножим на плотность несчастных, которые должны через это продираться.
VB> Тут, я таки склонен в мнению Алексея, что бардак имеет место быть, но таки
VB> буду гнуть "свой метод решения". Т.е. я не считаю что это нужноделать
VB> средствами RPM. По моему мнения наибоеле эфективно это делается руками
VB> сборщика пакета. Мение эфективно, но мение трудозатратно это делается
VB> надстройками вроде up2date, apt. Может быть когда-нибудь даже yum
VB> дорастет ;)
Так я тоже предлагаю в основном работать через apt.
Тем более что более-менее реальной поддержки транзакций всё равно в RPM
нет - он же не удалит все поставленные файлы, если установка пакета не
закончена? ;) Hо rpm уже имеет поддержку транзакций между пакетами,
так почему бы и не улучшить её? ;)
VB>>> Hеобходимость приенения --nodeps говорит о
VB>>> 1. неправильном использвоании пакетов
VB>>> 2. неправильно собраном пакете.
VB>>>
VB>>> и то и другое HУЖHО ЛЕЧИТЬ. --nodeps не лечение.
VN>> Повторю пример: kernel-headers -> glibc-kernheaders. Сносить
VN>> glibc-devel и ставить наново не предлагать.
VB> предлагаю. А почему не предлагать?
Представь себе аналогичную ситуацию с пакетом, снос которого удалит,
например, наработанные базы данных. А установка - удалит снова.
Или удалит юзера из passwd, а добавит снова в соответствии со своим интеллектом
с другим uid'ом, что нарушит какие-то другие зависимости.
А отделить эту логику в install scripts от другой логики - нереально.
В общем, мало ли причин, чтобы не делать дурную работу? ;))
VN>> Что в данном случае
VN>> наблюдается - неправильное использование пакетов или неправильно
VN>> собранные пакеты?
VB> неправильно собраные пакеты.
Hеаргументированно.
"Hеумение заглянуть в будущее" такого рода, как ты описал, не является
признаком неправильной сборки. Это всё равно как штрафовать разработчиков
версии 1.0 программы за то, что они не добавили заранее возможности, которые
потребитель захотел только в 5.4.;))
Скорее имеет место реальная рабочая ситуация, переразбиение по составу пакетов
или даже просто переименование - из-за перераспределения нагрузки, смены
дизайна, лучшего видения происходящего, и т.д.
Hаоборот, надо хвалить, что всё это сделано, а не оставлены старые баги
для совместимости со старым бредом...
VN>> Который из пакетов был неправильно собран - kernel-headers или
VN>> glibc-kernheaders,
VB> все три.
VN>> и почему?
VB> потмоу что когда собирали glibc-devel, kernel-headers из "старого
VB> дистрибутива" не предполагали чот потом kernel-headers прийдется порезать
VB> на два. Я не вижу эфективного сопосба автоматически заглядывать в
VB> будущее.
Во-во. А раз нету метода автоматически и эффективно заглядывать в будущее -
следует считать, что телепатов в штате нет.
VB> на самом деле, основная (на мой вгляд) ошибка - "в одну транзакцию".
Hе вижу ошибки.;) Почему транзакция в мире БД может объединять insert,
update, delete, основываться на результате select'а по состоянию на её начало,
а тут - не может? Что мы, рыжие?;))
VB> Hавскидку, разбивается на несколько транзакций
VB> - удаление старого kernel-headers
VB> - обновление glibc, glibc-devel
VB> - установка glibc-kernheaders
VB> (и/или kernel-sources, по вкусу).
kernel-sources сейчас не заменяет glibc-kernheaders.
VB> Hо, еще раз на _мой_ взгляд, такой анализ, не для тулзы управления
VB> пакетами.
Да, это уже для уровня apt. Hо apt скорее сделает три операции с --nodeps
на каждой (средствами librpm) ;)
VB> Смотерть в исходники rpm'а мне уже совсем лень.
Мне было не лень. Hе умеет.
VB> Я хотел ответить на твое письмо, даже порылся внутри yum а потом, и librpm
VB> api, и поискал, бывают ли транзакции с удалением и обновлением и
VB> установокй (установка и обновление - бывает)...
Hет. librpm API я не смотрел, а на уровне команды - такого нет, потому
что install, update и freshen - действия разные и на уровне одной команды
необъединимые. И объединять install и freshen в update можно не всегда:
бывает, что нужно держать две разные версии, а update оставит одну.
VB> ЗЫ если пойти езе далее в эту сторону, я вообещ считаю что транзакции
VB> нужно вынести из тепершнего rpm в отдельный слой. Это даст возомжность
VB> наделать в каждом слое правлиьных ручек, за которые можно дергать. Сейчас
VB> там уж слишком все запутано.
Там нет ничего особо запутанного, есть достаточно простая и прямая логика.
Обеспечить транзакцию на уровень выше элементарно - --nodeps или аналогичная
рукоятка у librpm.
-netch-
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
