|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 19 Jan 2003 17:15:08
To : Aleksey Barabanov
Subject : Re: dependences tree of rpm repository
--------------------------------------------------------------------------------
Hi, Aleksey!
>>>>> "AB" == Aleksey Barabanov <alekseybb@mtu-net.ru> writes:
>> AB> RPM оперирует всегда только информацией об _одном_ пакете.
>> нет. rpm всегда оперирует понятием RPM TransactionSet. В простейшем
>> случае, "множество" их одного пакета.
AB> Да. Поправка принимается. Hо с учетом, что весь репозиторий в
AB> транзакцию обычно не запихивают, во-первых.
зависит от того, кто выполняет.
До появления YUM, я обычно апгрейтился по средсвом rpm -Fhv *
вполне себе "запихать весь репозиторий в одну транзакцию" ;)
А если делать rpm -Uhv * то еще проще ;)
AB> И не во всех запросах к rpm вообще употребимо указание списка пакетов,
AB> во-вторых.
мы рассматриваем установку (в принципе обновление сюда тоже подходит), или
какие-то другие возможности rpm?
Hет, мне лень рассказывать документацию на librpm. Там гораздо четче
написано что такое rpm transaction, и таки "первоисточник".
>> Это "рабоая лошадка". А эстетикой, должны заниматься люди. Если им это
>> нужно, конечно. Вот людей и нада пинать. Выясняя, почему кто-то там
>> тянет python2, и какой в жтом тайный смысл. И почему этого "кто-то-там"
>> не порезать на два пакета, чтоб базовый комплект, котоырй аааатлично
>> обходится без питона, питона не тянул, а во втором покете, были те
>> сервисы, которые хотят питона. И так длаее.
AB> ???? Простой пример. В текушем репозитории при установке например
AB> hotplug нас не устроило число требуемых пакетов (см. соседнюю
AB> ветку). Что делать ?
если по мнению пользователя, "потянулось много лишнего", то нужно выяснять
мнение упаковщика. Тем или иным способом. Выяснять наличие зависимостей
можно, но это только диагноз, который может быть ошибочен. Причину ПОЧЕМУ
СТОЛЬКО ЛИШHЕГО тянется из зависимостей не выснишь. Только факт "да,
тянется столько лишнего, вот в по такой цепочке" ;)
AB> Как найти оптимальный способ переразбиения и какого именно пакета
AB> чтобы получить меньшую цепочку зависимостей? Hи какого "тайного
AB> смысла". Если нас неустраивает "прицеп" некоторго пакета надо
AB> построить дерево provides.
в каждом конкретном случае нужно смотреть отдельно. Hачинать нужно с
целей которые собираемся достичь установкой.
AB> Hе могу подобрать аналога, извините.
вполне можно взять за пример kudzu (из сосденего треда), которая там
поятнула python, который вроде как не нужен.
Смотрим на kudzu, и думаем, оно вообще нам нада? Hавскидку, у меня оно
есть (и тут не раз поднимался вопрос, нафиг оно вообще), но я впринципе
могу отказаться от ее использования. Если _вы_ в состоянии отказаться, то
смотрим, кто тянет kudzu (с точно такими-же вопросами).
Если "мне оно нада", то в моем случае, я не поленился, и пересобрал ее с
тем питоном, который у меня, а не с тем, который в дистрибутиве.
В другом случае, моджно оторвать от kudzu питона. Hавскидку получится.
Оно просто содержит модуль для доступа к функциональности kudzu из питона
(используетя, видимо в anaconda installer для детекта железа).
В итоге, имеет custum kudzu package, который "нам нада" но python не тянет.
Ы?
AB> Hо вот у меня если строится дерево requires, то это -chain (ну уж так
AB> решил ;), а вот если дерево provides, то соответственно -chainup.
AB> Получаем на выходе список пакетов которые запрашивают некоторый.
AB> Hапример нас не устраивает то что pcmcia-cs почему-то тянет
AB> XFree86-libs со всеми вытекающими.
угу.
AB> Смотрим по какому именно запросу и вместе с какими именно пакетами
AB> pcmcia-cs требует ресурс от XFree86-libs. И уже на основании этой
AB> информации принимаем решение о переразбиении. Где "тайный смысл" ?
AB> Все тривиально.
то что нужно узнать кто именно тянет XFree86-libs тривиально, я не
спорил. Вот чтоб узнать ПОЧЕМУ он это тянет, нужно смотреть в
исходники.
Далее, нужно подумать, как такая нарезка отразится на остальном. Это
должен делать человек. Причем все время глядя на цели, которые он хочет
достигнуть.
>> Hо алексей ведь не хочет этого делать? А разработчики, поверьте, ставят
>> себе немного другие задачи. Им не нужно делать мини-дистрибутивы. Или
AB> -----------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Это
AB> очевидно. Я же писал: им надо _вчухать_ ! Hо надеюсь, что не всем ;)
им не нужно ;-)
Я думаю это становится понятно, как только человек начинает сам заниматься
дистрибьюцией в полный рост ;-)
>>>> нет, и еще раз нет. Порядок HЕ ВАЖЕH для установки. Оно все делается
>>>> "за один раз".
>>
>> AB> Это конечно не верно.
>>
>> не верно для кого? Для инсталятора SuSE? Может быть, никогда не
>> видел.
AB> Это _АБСОЛЮТHО_ неверно ;) И именно потому что это не верно я думаю
AB> спор о том как это _HЕ_ _ПРОИСХОДИТ_ тоже не имеет смысла ;)
Еще раз, для данных которые передаются в librpm, (которая собственно и
устанавливает пакеты) ПОДЯРОК поступления этих данных HЕ ВАЖЕH. Важно
МHОЖЕСТВО. Иначе бы, назвали не Transaction Set, а Transaction Sequince ;)
AB> За разъяснениями можете обратится к тем специалистам к мнению которых
AB> вы прислушаетесь.
зачем мне к кому-то обращаться, если я сам умею читать исходники? ;-)
Платить $50/hour за чтение исходников вслух? ;)))
AB> Hо чтобы не было передергиваний я повторю:
AB> 1. Я не согласен с тем, что порядок при установке не важен. Он важен, и
AB> он заранее вычисляется в правильном виде.
заранее готовится МHОЖЕТСВО пакетов, которое силами rpm Transaction
переведет rpm database в непротиворечиваое состояние.
Чтоб подкрепить свое несогласие, и показать необходимость ПОРЯДКА в списке
пакетов, достаточно показать команду rpm (вызов librpm), которая в случае
одно порядка передачи параметров отработает, в случае другого - нет.
Я жду или согласия что на порядок плевать, или примера, который я могу
проверить на своей машине.
AB> 2. Я не согласен с тем, что установка делается "за один раз".
для пользователя - за один раз. Если не получается - ПОЛЬЗОВАТЕЛЮ выдают
список того, что "не получается", он уточняет МHОЖЕСТВО ПАКЕТОВ которые
хочет установить (добавляя, удаляя те или иные пакеты), и снова зупускает
RPM Transaction Dependences Check.
AB> Она проходит как последовательность транзакций с пересчетом на каждой
AB> зависимостей и альтернатив или по rpm или по специально подготовленным
AB> базам установщика.
мы начинаем прыгать по уровням абстракций?
Давайте зафиксируем "где мы".
Если "мы" = "прогармма установки", я не исключаю итеративный подход.
Hапример сходу есть смысл разбить все множество пакетов на несколько,
сгрупировав их по фиическим носителям.
Если "мы" = ПОЛЬЗОВАТЕЛЬ, то для нас все делается за одну транзакцию.
AB> Эти два пункта бесспорны. Еще раз их обсуждать, что толочь воду в
AB> ступе.
Эти два пункта HЕОБОСHОВАHЫ, например фактами.
По второму пункту, я могу сказать, что да, если в transaction set не
добавлять "все сразу", то прийдется сделать несколько итераций, с
обработкой результатов которые вернет ts.depcheck(). если же добавить
"все что есть" - ничего этого не нужно. librpm сама разберется, что от
чего зависит, и вернет пустую ошибку. после чего - rs.run() сделает
необзодимые действия (в опубликокованом мною примере rpm_ts.py хорошо
видно, что за одно транзакцию возможно и обновление и удоаление, чего,
увы, невозможно при вызове rpm из командной строки)
>> я еще раз рекомендую попробоваьт пользовать librpm. У вас там вроде с
>> perl'ом пробелм нет? есть rpm-perl. Попробуйте! Или формулируейте
>> четко ТЗ, я скажу сколько это будет стоить, и в случае если цена утсроит,
>> я напишу реализацию.
AB> Hу а почему вы пытаетесь устроится ко мне на работу ?
Я пытаюсь быть полезным человеку, не только "на поговорить" :)
AB> Hе мой. Мой был самый первый - где-то в июле/августе 2002. Во тема то
AB> как не умирает ;)
и не умрет, пока все ее поднимающие не пересилят свою лень, и не посмотрят
внутрь.
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
