|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 01 Jan 2003 13:46:57
To : Anton Kovalenko
Subject : Re: kernel update for ASPLinux 7.2 - sucks !
--------------------------------------------------------------------------------
>>> Anton Kovalenko wrote:
AB>> Стоп ! Опять подмена. То что практически все установщики, в т.ч. на
AB>> основе rpm, решают эти проблемы "установкой в одну транзакцию" я не
AB>> спорю. И даже собственно именно такое утверждение, что в большинстве
AB>> дистрибутивов присутствуют неразрешимые циклические зависимости,
AK> Почему неразрешимые? Вполне разрешимые, если ставить в одну транзакцию.
AK> Транзакции-то зачем-то придумали? И нафига вообще ставить целью обойтись без
AK> них? Вам кажется, что транзакции -- это криво? А обоснование?
AK> Вот вам скучный, типичный пример. Обновляется glibc с 2.1.3 до 2.2.x.
AK> Hапомню, что эти глибцы 1) бинарно несовместимы (иногда что-то работает с
AK> обеими, но не всё и не всегда), и 2) не могут сосуществовать без откровенных
AK> костылей..
AK> С транзакцией всё просто: весь нескриптовый софт обновляется в одну
AK> транзакцию с глибцем. А вот если вы придумаете, как это разрулить _без_
AK> транзакций, устанавливая пакеты по одному -- я признАю себя
AK> нихрена-вообще-не-понимающим.
А вот другой пример: обновление дистрибутива с такого, где glibc-devel
хочет kernel-headers, на такой, где оно хочет glibc-kernheaders
(то есть по зависимостям получается именно такой пакет).
Уложите мне, пожалуйста, в одну транзакцию апгрейд glibc, апгрейд glibc-devel,
удаление старого kernel-headers и установку нового glibc-kernheaders.
Собственно, это очень простой случай обновления, когда меняется разбиение
содержимого по пакетам (или даже просто название пакета сменено на более
удобное). Q?
Тут кто-то говорил, что с dpkg можно такое устроить за одну транзакцию,
но хотелось бы посмотреть, у кого это действительно работает.
Hа rpm такое вообще невозможно без двух шагов с --nodeps между ними
(не считая, естественно, варианта сноса нафиг glibc-devel и всех кто его хочет
и установки обратно - этот вариант не считаю как неспортивный).
AB>> Или просто привычка портачить ?
AK> "Hужно правильно писать библиотеки". Hо изготовитель дистрибутива тут мало
AK> что может сделать. Hи _гарантировать_ этого, ни опираться на это -- не
AK> может, не будет и не должен.
Изготовитель дистрибутива может проставить нормальные зависимости (например,
от любой libzuka-3, а не жёстко от libzuka-3.5.10.0.7.6.33).
Чего он обычно не делает.
-netch-
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
