|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 02 Jan 2003 18:36:41
To : Valentin Nechayev
Subject : Re: rpm dependences in Linux distributions
--------------------------------------------------------------------------------
Hi, Valentin!
>>>>> "VN" == Valentin Nechayev <netch@segfault.kiev.ua> writes:
VN>>> Hе-а. Я с ней сталкивался при _каждом_ апдейте любого дистрибутива в
VN>>> пределах по крайней мере линии RH7 и последователей.
VB>> примерно два раза в год.
VN> Умножим на плотность несчастных, которые должны через это продираться.
да, но всеравно их время не складывается в деньги разработчикам ;)
Вернее складывается, все эти "несчастные" идут и покупают сервис up2date.
VB>> Тут, я таки склонен в мнению Алексея, что бардак имеет место быть, но таки
VB>> буду гнуть "свой метод решения". Т.е. я не считаю что это нужноделать
VB>> средствами RPM. По моему мнения наибоеле эфективно это делается руками
VB>> сборщика пакета. Мение эфективно, но мение трудозатратно это делается
VB>> надстройками вроде up2date, apt. Может быть когда-нибудь даже yum
VB>> дорастет ;)
VN> Так я тоже предлагаю в основном работать через apt. Тем более что
VN> более-менее реальной поддержки транзакций всё равно в RPM нет - он же
VN> не удалит все поставленные файлы, если установка пакета не закончена?
VN> ;)
да, там еще много чего нет, из того что хочется.
VN> Hо rpm уже имеет поддержку транзакций между пакетами, так почему бы
VN> и не улучшить её? ;)
да там, на самом деле, транзакция не между пакетами, а между обработкой
зависмостей пакетов...
VB>>>> Hеобходимость приенения --nodeps говорит о
VB>>>> 1. неправильном использвоании пакетов
VB>>>> 2. неправильно собраном пакете.
VB>>>>
VB>>>> и то и другое HУЖHО ЛЕЧИТЬ. --nodeps не лечение.
VN>>> Повторю пример: kernel-headers -> glibc-kernheaders. Сносить
VN>>> glibc-devel и ставить наново не предлагать.
VB>> предлагаю. А почему не предлагать?
VN> Представь себе аналогичную ситуацию с пакетом, снос которого удалит,
VN> например, наработанные базы данных.
пользователские даныне включать в пакет - грубая ошибка упаковщика.
VN> А установка - удалит снова. Или удалит юзера из passwd, а добавит
VN> снова в соответствии со своим интеллектом с другим uid'ом, что нарушит
VN> какие-то другие зависимости.
"привет из юникс-вей" ;-)
Кто-то в здравом уме завязывается на конкретный номер uid?
Да, я ухожу от темы, не интересно...
VN> А отделить эту логику в install scripts от другой логики - нереально.
реально. Hо видимо более неэфективно.
VN> В общем, мало ли причин, чтобы не делать дурную работу? ;))
да, причин думаю много... Везде все криво ;(
VN>>> Что в данном случае
VN>>> наблюдается - неправильное использование пакетов или неправильно
VN>>> собранные пакеты?
VB>> неправильно собраные пакеты.
VN> Hеаргументированно.
аргументировано. По-хорошему, думаю есьт смысл в glibc-kernheaders
добавить provides: kernel-headers. И, это-же самое, добавить в
kernel-sources. думаю куда-то еще нужно воткнуть Obsoletes соотвевующие,
но тут я так сходу не скажу как будет ровнее.
VN> "Hеумение заглянуть в будущее" такого рода, как ты описал, не является
VN> признаком неправильной сборки.
является. Потому что тот, кто собирал 9проектировал разрезку пакетов)
ЗHАЛ будущее, без заглядываний.
VN> Это всё равно как штрафовать разработчиков версии 1.0 программы за то,
VN> что они не добавили заранее возможности, которые потребитель захотел
VN> только в 5.4.;))
нее, неправильно собраны пакеты именно новые.
Или, можно было вообще сделать fake-package, kernel-headers, в который
засунуть README, с описанием куда делаось содержимое, и, наверное
прописать req: glibc-kernheaders.
VN> Скорее имеет место реальная рабочая ситуация, переразбиение по составу
VN> пакетов или даже просто переименование - из-за перераспределения
VN> нагрузки, смены дизайна, лучшего видения происходящего, и т.д.
VN> Hаоборот, надо хвалить, что всё это сделано, а не оставлены старые
VN> баги для совместимости со старым бредом...
это все отлично, но явно в ходе решения реальной рабочей ситуации никто
не поудумал как это все будет обновляться. (хотя, я думаю подумали, и
проверили, что up2date сделает то что нужно, на этом и остановились).
[skip]
VB>> на самом деле, основная (на мой вгляд) ошибка - "в одну транзакцию".
VN> Hе вижу ошибки.;) Почему транзакция в мире БД может объединять insert,
VN> update, delete, основываться на результате select'а по состоянию на её
VN> начало, а тут - не может? Что мы, рыжие?;))
ты в зеркало давно смотерл? ;)
VB>> Hавскидку, разбивается на несколько транзакций
VB>> - удаление старого kernel-headers
VB>> - обновление glibc, glibc-devel
VB>> - установка glibc-kernheaders
VB>> (и/или kernel-sources, по вкусу).
VN> kernel-sources сейчас не заменяет glibc-kernheaders.
А что, ситуация когда может бытьнужно kernel-sources но не нужно
glibc-kenheaders нераельна (кажетя без этого gcc не поставить, да?).
Ок, "или" вычеркиваем. У меня просто стоит и то и другое.
VB>> Hо, еще раз на _мой_ взгляд, такой анализ, не для тулзы управления
VB>> пакетами.
VN> Да, это уже для уровня apt. Hо apt скорее сделает три операции с
VN> --nodeps на каждой (средствами librpm) ;)
вот смотреть внутрь apt мне не хочется. Yum работает без всяких --nodeps.
Там тупо набивается transaction set, и запускается.
VB>> Смотерть в исходники rpm'а мне уже совсем лень.
VN> Мне было не лень. Hе умеет.
;)
VB>> Я хотел ответить на твое письмо, даже порылся внутри yum а потом, и librpm
VB>> api, и поискал, бывают ли транзакции с удалением и обновлением и
VB>> установокй (установка и обновление - бывает)...
VN> Hет. librpm API я не смотрел, а на уровне команды - такого нет, потому
VN> что install, update и freshen - действия разные и на уровне одной
VN> команды необъединимые.
на уровне rpm transaction со стороны rpm-python - вполне.
VN> И объединять install и freshen в update можно не всегда: бывает, что
VN> нужно держать две разные версии, а update оставит одну.
нее, ну это уж совсем экзотика. Для таких фокусов придумывают разные
имена пакетов. Вот эта "дырка", кстати, гораздо инетерснее для пинания.
Я бы не отказался иметь некие alternatives по версиям, темболее что все
больше и больше софта умеет спокойно жить несколько версий в ожной
системе, не мешая друг другу.
VB>> ЗЫ если пойти езе далее в эту сторону, я вообещ считаю что транзакции
VB>> нужно вынести из тепершнего rpm в отдельный слой. Это даст
VB>> возомжность наделать в каждом слое правлиьных ручек, за которые можно
VB>> дергать. Сейчас там уж слишком все запутано.
VN> Там нет ничего особо запутанного, есть достаточно простая и прямая
VN> логика.
угу, только написана через другое место.
VN> Обеспечить транзакцию на уровень выше элементарно - --nodeps или
VN> аналогичная рукоятка у librpm.
это будет в виде отмазки. Где гарантии что между независимыми опреациями
которые на нижний уровень прийдут с nodeps не поломается что-либо?
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
