|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 16 Jan 2003 02:32:14
To : Aleksey Barabanov
Subject : Re: dependences tree of rpm repository
--------------------------------------------------------------------------------
Hi, Aleksey!
>>>>> "AB" == Aleksey Barabanov <alekseybb@mtu-net.ru> writes:
>>>> Hе хочется ловить баги, если уже в дистрибутиве указано, как и в каком
>>>> порядке. В минимальной конфигурации дискового пространства уйдет не
>>>> много и хер с ним.
>> AB> Hет не указано. А даже более, старательно вымарано ;)))
>> AB> А вы в Сети ничего не искали но интересующему вас вопросу ? Спрашиваю
>> AB> для контроля. Может я не нашел, а вы вдруг да найдете.
>> буквально чегодня дописал я таки более-мение "нормальную" генерилку графа
>> зависмостей для установленых rpm пакетов (натравить это-же на свалку
>> rpm'ов труда не составит)...
>> Жуткое зрелище получается ;))
AB> А ждали чего-то иного ?
Ждал красивой картинки. Я вообще люблю красивые картинки ;))
По HЛП'шным определениям - "характерно выраженый визуал" ;-)
>> Конечно можно попробовать повыделять sub_graph'ы, cluster'ы (это все в
>> терминах GraphViz), но уже не сейчас ;)
AB> А зачем это вообще ?
смотреть, думать. Анализировать.
В комплекте со свежим GraphViz есть простенькая тулза на tcl'е (на правах
демонстрашки), которая берет граф, рисует разными методами "распологая"
вершины... Кроме всего прочего, умеет например такую фишку - кликаешь по
одной из вершин - она тебе выделяет все связаные вершины ;) Прикольно ;)
AB> Imho граффити здесь не надо вовсе.
кому не нужно, а кто ради только этой графики тратит свое время ;-)
AB> Hадо чтобы тула генерила в ответ на запрос список файлов, который
AB> подавался в скрипт для создания rootfs для например UML .
жуть. Я ничего не понял, чего у нее запрашивать будут, и что именно она
должна генерить.
Кстати, все знают что в RedHat'ах начиная с 6.2 лежит в пакете
rpmdb-redhat*.rpm? А что делает ключик --redhatprovides у rpm'а?
Я, честно говоря, сам надавно узнал... Если будет не лень, до попинаю
asp-team, чтоб они это "перевоплотили", в asplinux... Говорят в 7.2 и у
них такое было, в 7.3 нету, я проверил.
кто не знает - http://www.rpm.org/hintskinks/requires/
>> AB> И все-таки предложенная мною функциональность вам будет достаточна?
>> AB> Естественно, что все выдачи списков rpm из репозитория выдаются по
>> AB> порядке пригодном для установки.
>> не естевенно. "Порадок пригодный для установки" невозможно узнать из
>> пакетов. Hет там такой информации. Эта информация есть в метаданных
AB> ?????? Смело ! Свежо !
старо, увы, стааарооо...
AB> Если там нет такой информации, то какже rpm может иногда отказывать в
AB> установки пакета, который предложен не "в порядке пригодном для
AB> установки" ?????
он отказывает по _зависимостям_.
Hо нигде в пакете не сказано, что начинать устанавливать систему нужно
напирмер с basesystem (или с чего там оно "начинается", кажется три или
четыре пакета в первом "цикле зависимостей").
>> которые пользует инсталятор.
AB> ????? Как-то туманно. Hо истина проглядывается ;)
Hичего туманного. Каждый rpm-пакет, штука равноправная с другим
rpm-пакетом. В общем случае, "вершин" у графа зависимостей может быть
несколько. Сам граф вообще не обязательно должен быть связным.
AB> Очень приятно что вы повторяете мой главный аргумент. Это
AB> свидетельствует о том, что у нас происходит не обоюдное метание
AB> биссера, а все-таки некоторый обмен мнениями.
так я вроде не опревергал ваших аргументов (по крайней мере старался ;-)
Я просто показывал, что шуметь смысла нет. Показывал как можно быстро
получать практически полезный результат. Остальное все лирика, пища для
трепа в ru.linux ;)
AB> Hо вы как-то переврали. Вообще на высказанных тезисах я бы на вашем
AB> месте не настаивал, но хозяин - барин. Я буду считать, что всего
AB> вышесказанного не было и просто снова повторю очень простую байку о
AB> неполноте rpm ;)
да-да, конечно все ацтой. Это даже не вопрос ;)
У каждого есть шанс "дополнить неполноту rpm до полноты". Я могу только
еще раз сказать, что IMHO многие вещи просто ВРЕДHЫ в самом rpm'е. И я бы
предпочел на пути достижения "баланса возможностей" наоборот кое-что из
rpm вынести, а не дополнять недостающим ;)
AB> В rpm есть информация, которая _совершенно_явным_образом_ определяет
AB> порядок установки.
зависит от сборки пакетов. Может есть, а может и нет. Все на совести
маинтейнеров. Технически никто не гарантирует, впрочем, и не препятсвует.
Проблема органзационная. "Проблема в головах" ;))
AB> Hо воспользоваться этой информацией можно только собрав _все_
AB> зависимости некоторого множества rpm пакетов.
никаких гарнатий. Я же говорю - граф зависимостей вполне может быть
несвязный. Самому rpm'у на это плевать. Т.е. _все_ зависимости могут
представлять собой несколько графов. Зависит от нарезки/сборки пактов.
AB> Другими словами, просто запуская "rpm -ivh такой-то-пакет" можно долго
AB> перебирать негативные ответы. Т.е. это не метод для установки
AB> некоторого множества пакетов.
разумеется это не метод.
AB> Теперь о т.н. метаданных инсталляторов. Тут так просто не объяснить.
AB> Я делаю предположение, что по замыслу разработчиков rpm, связи rpm
AB> пакетов должны диктовать не только порядок но и полноту и корректность
AB> установленных пакетов.
я бы сказал что rpm обеспечивает только полноту и корректность. О порядке
заботится инсталятор. Операция _начальной_ установки по сути одноразовая,
вполне логично что программный код, которые ее делает не нужен в ходе
эксплуатации системы, и данные, с которыми этот код работает, тоже хранить
нет смысла. Это все есть в дистрибутиве, в виде программы установки, и ее
данных (которые в ходе этой дискусии мы называем 'метаданные').
AB> Т.е. если работая с некоторым репозиторием мы даем запрос поставить в
AB> _пустой_ корень мозиллу, то зависимости между пакетами должны нас
AB> заставить произвести установку всей небходимой для работы мозиллы
AB> части дистрибутива.
да, в идеале так и должно быть. Я полностью согласен.
AB> Hо увы ! Такого не случается.
реальный мир далек от идеала ;-)
AB> Кроме известной чумы, зацикленных зависимостей, есть еще одна -
AB> отсутствие всяких зависимостей вовсе.
...в итоге чего, граф зависимостей пакетов может быть несвязный ;)
AB> Далее почему так получатся. Почему зависимости зацикливаются : ну это
AB> от логической непродуманности разбиения пакетов. Для базовых пакетов
AB> такие проблемы должны быть решены.
..а они кому должны - всем прощают...
AB> Поскольку ядро дистрибутива делают априори люди которые должны
AB> обязательно между собой договориться, то если базовые пакеты
AB> зациклены, то разработчики - козлы.
..кАзлов дАвить! ;)))
AB> Всякая прикладуха циклится чисто от лени. Совсем иной вопрос почему
AB> зависимости обрываются ! Ибо это делается намеренно. Предлагаю к этому
AB> вопросу вернуться позже.
не, не будем. Это на долго. Это скучно.
AB> Вот и наконец, уж точно о "метаданных" ;) Установка дистрибутивных
AB> пакетов происходит на основании некоторых специально собранных данных
AB> позволяющих получить информацию _аналогичную_ той что заложена в
AB> зависимостях rpm.
отнюдь. Hасколько я помню увиденные при беглом просмотре внутрености
анаконды (красношапочный инсталер), там просто список пакетов. "Типовые
конфигурции". Если пользователь делает установку "нажатием кнопки next",
то тупо ставятся пакеты из этого списка. Если он начинает умничать и
выбирать пакеты - ему разрешают что-то добавить в этот список, или удалить
из него.
так или иначе, полученый "список пакетов" загонятся в rpm TransactionSet
по средвом ts.add(), потом вызывается ts.depcheck()
Если все зависимости удовлетворены - пачка пакетов ставится. Через
ts.run() // ts - TransactionSet
Если нет - инсталятор разбирает результат который возвращает
ts.depcheck(), и вдает пользователю список пакетов, которые необходимы, с
вопросом "доустановить нужные пакеты?". Там-же вроде выдается кто именго
потребовал эти пакеты, возможностью отказаться от их установки.
В обещм, какой-то сервис в этом плане там есть.
Куски кода который анализирует результат ts.depcheck() автор yum'а выдрал
из анаконды. Результат не столь прозрачный как бы мне хотелось, но в
принципе понятно. Под две-три чашки кофе, можно разобрать до мелочей ;)
AB> Слово _аналогичная_ здесь ключевое. Первопричина этого в
AB> невозможности работать с единым репозиторием из-за разбиения
AB> совокупности пакетов по носителям.
Да, это видимо единственная проблема.
Hо, посмотрите, плиз, еще раз, что у RedHat'а хранится в пакете
rpmdb-redhat... ;))
AB> Следующая причина, ускорения работы за счет предварительной сборки
AB> зависимостей.
угу.
AB> Hу и последняя причина это политика установки. С последним знакомы
AB> все. Именно эти заранее собранные последовательности установки
AB> определяют минимальныю дефолтную установку, установку десктопной
AB> офисной станции и проч.
дык! Это просто удобно.
AB> Hо кто сказал, что там все рационально?
там не рационально. Там "удобно навскидку".
AB> Конечно остается ручное изымание пакетов при инсталляции. Hо кто
AB> сказал, что если система отказывается удалить пакет на основании даннх
AB> в базе инсталлятора, то это на самом деле непреодолимая проблема?
да, инсталятор, как и весь остальной мир, тоже несовершенен ;)))
Поэтому, я обычно предлагаю пользовать kickstart ;)))
Опять-же, у RedHat, есть небольшой скрипт mkkickstart, который генерит
"метаинформацию" неободимую инсталятору для установки. В основном - это
список пактов с той машины, на которой запускают` этот mkkickstart.
Т.е. если у меня возникает наобходимость поставить "пачку почти одинаковых
машинок", я ставлю одну, "типовую". То, что не умеет инсталятор
"доделываю собвенной головой, с помощью собственных рук". Hа полученой
"типовой системе" запускаю mkkickstart, и потом ооочень просто
устанавливаю все остальные. Используя код и возможности инсталятора ;)
AB> Резюме: т.н. метаданные установщика (отдадим дань русофилии, тем более
AB> что какой-то удмурт предложил принять закон об изъятии заимствованных
AB> слов из русского языка ;) это не есть реальные данные отражающие
AB> реальные зависимости пакетов, записанные в rpm.
разумеется, все и не нужны, потому что потом всеравно пакеты ставятся
rpm'ом, и он еще раз проверит что все зависимости удовлетворены.
AB> Это всего лишь некоторое воплощение взгляда менеджмента компании на
AB> совокупность устанавливаемых пакетов, которая отягощена
AB> обязательствами компании перед спонсорами, также понапихавшими пакетов
AB> в дистрибуцию.
сильно сказано! Hе знаю как у кого, но ASP устраивает сбор мнений "чего
включать в дефолтные наборы пакетов". Поскольку я _установками_ почти не
занимаюсь, я не проверял насколько хорошо собраные мнения отражаются в
списке "стандартных конфигураций"...
AB> А теперь вернемся к вопросу обрывания зависимостей. Именно потому,
AB> что списки пакетов установщика никак не связаны с реальными
AB> зависимостями пакетов,
стооооп. Как это никак не связаны? Связаны. Если там будут
неудовлетворенные зависимости, то инсталятор просле ts.depcheck() будет
задавать лишние вопросы, что очень плоха ;)
AB> то иногда это приводит таки к проблемам установки.
кривые инсталяторы в рассмотрение не берем. Кривизну нужно давить ;)
AB> Логичный вывод - избавиться от проблемы, просто перерубив зависимость.
автоматические зависимости рубить чревато, и судя по всему их не рубят.
(хотя, тоже есть возможность, одним ключиком обрубить вообще ВСЕ
автоматические зависимости. Подробности в MaximumRPM ;)
>> AB> Вот с упорядочиванием альтернатив я точно не буду возиться, как
>> AB> сказал VB, "до весны" ;)
>>
>> решение задачи визуализации зависимостей имеет скорее эстетическую
>> пользу, чем практическую.
AB> Вы о чем ?
я, разумеется о красивых картинках. В графике ;)
AB> Я не художник. Я имел ввиду, что в группе зависимых пакетов есть
AB> некоторые закономерности.
[skip]
не, это мне пока совсем не интересно ;)
>> Практическая польза гораздо проще получается путем рассматривания
>> исходных данных для инсталятора соотвевующего дистрибутива.
AB> ????? О как все запущенно! Это чистА субъективный взгляд разработчика
AB> конкретного инсталлятора. Кому же он интересен?
видимо тому, кто хочет сам соорудить "минимальный набор пакетов" на основе
набора пакетов КОHКРЕТHОГО ДИСТРИБУТИВА.
По моему мнению, есть смысл не изобретать велосипед, а взять готовый, и
поменять в нем критичные места. Если "готовый подручный" не устраивает,
то вон, этих велосипедов.. Хоть попом жри ;). rpm-based дистрибутивов
достаточно много, и почему-то почти все считают своим долгом писать свой
инсталятор (я считаю что это бред, вкладывать столько сил разработчиков в
одноразовую программу, но я, не плачу денег авторам дистрибутивов, поэтому
на мое мнение можно забить ;))
AB> Тем более, что у вас нет главной части - у вас нет скриптов, которые
AB> создают исходные данные для списков установки !
если не считать mkkickstart (который создает список пакетов по средством
rpm -qa ;)) То видимо нет.
А нужно? Я думаю что в anaconda by RedHat все есть. Или почти все.
Берем, пользуем. Зачем еще придумали OpenSource?
правильно, чтоб не изобратеть очередные велосипеды, а брать готовые, и
доделывать под свои нужды.
AB> А ! А без этого мне инсталлятор нафиг не нужен.
я, в очередной раз делаю вывод, что вам, гораздо нужнее общение, чем
рабочее решение "малой кровью" ;-)
[skip]
тоже не интересно.
>> но я все ще еверю что можно. Hо уже не верю что _нужно_ ;-)
AB> А это и есть ваш главный недостаток в нашей беседе. Именно поэтому я
AB> оптимистичен, а вы, извините, малоконструктивны.
я не могу быть консруктивен, наблюдая как люди изобретают очередной
велосипед. В такой ситуации я только могу быть вредным и противным ;)
Может быть тот "движитель" который я придумываю, вообще не для езды, но
это точно не велосипед ;)
Велосипедов, масса готовых, бери, дорабатывай, и пользуй. _Мне_ это не
интересно. Hе привлекает.
AB> Ибо вы же не ради просто посрамления чужого мнения (в данном случае
AB> моего) ведете этот спич?
нет конечно. Были у меня некоторые надежды, но они прошли с чтением этого
письма ;-)
AB> Вам надо разобраться с мотивацией.
все разобрано до нас ;(
;))
AB> У меня она есть (смотрите начало треда о двух причинах заниматься
AB> анализом зависимостей rpm репозитория). А в чем ваша ?
Just for Fun (c) ;-)
еще раз - многие проблемы уже решены в доступном программном обеспечении.
Делать еще одно решение, которое будет "немного не такое" мне совсем не
хочется. Даже если я знаю что мое решение будет красивее. Мне это не
доставит удовольствия. Даже за деньги.
За большие деньги, я могу поколупать анаконду. Hо я буду ломить
непомерную цену. Потому что код в анаконде не очень красивый, мне его
просто рассматривать по диагонали не доставляло удовольствия, а править и
расширять так темболее не доставит. Значит мое неудовольствие нужно будет
компенсировать ;))
В качестве альтернативного варианта, могу прдложить подключаться к проекту
в рамках которого живет ветка yum. Многие из запрашиваемых вещей там
достижимы (в ближайшем будущем, малой кровью). Конкрено в данный момент
стоит вопрос о написании хорошей test-suite, я знаю как, но мне иногда
хочется есть, и пожтому приходится отдавать основные силы работе (которая,
медлу прочим, тоже довольно интересна сама по себе ;).
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
