|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey Barabanov 2:5020/400 16 Jan 2003 12:38:42
To : Vladimir Bormotov
Subject : Re: dependences tree of rpm repository
--------------------------------------------------------------------------------
Vladimir Bormotov wrote:
> Ждал красивой картинки. Я вообще люблю красивые картинки ;))
> По HЛП'шным определениям - "характерно выраженый визуал" ;-)
Hо вы же сами мне указали урл на rpmgraph (или как он там называется). А там
и пример работы этого чуда приводится. Весьма мерзко.
> В комплекте со свежим GraphViz есть простенькая тулза на tcl'е (на правах
> демонстрашки), которая берет граф, рисует разными методами "распологая"
> вершины... Кроме всего прочего, умеет например такую фишку - кликаешь по
> одной из вершин - она тебе выделяет все связаные вершины ;) Прикольно ;)
Точно прикольно ;) Можно сделать аналог солитера для эхотага ;)
> AB> Imho граффити здесь не надо вовсе.
>
> кому не нужно, а кто ради только этой графики тратит свое время ;-)
No comment. Охота пуще неволи.
> AB> Hадо чтобы тула генерила в ответ на запрос список файлов, который
> AB> подавался в скрипт для создания rootfs для например UML .
>
> жуть. Я ничего не понял, чего у нее запрашивать будут, и что именно она
> должна генерить.
Придуряетесь, да ? ;)))
> Кстати, все знают что в RedHat'ах начиная с 6.2 лежит в пакете
> rpmdb-redhat*.rpm? А что делает ключик --redhatprovides у rpm'а?
У меня SuSE и в нем такого ключа нет. Поэтому если вы мне не скажите чтоже
он делает, я так и не узнаю.
> Я, честно говоря, сам надавно узнал... Если будет не лень, до попинаю
> asp-team, чтоб они это "перевоплотили", в asplinux... Говорят в 7.2 и у
> них такое было, в 7.3 нету, я проверил.
>
> кто не знает - http://www.rpm.org/hintskinks/requires/
Hу и чем это отличается от --whatprovides ? {у меня в todo тотже запрос но
по "сухому" репозиторию}.
> AB> Если там нет такой информации, то какже rpm может иногда отказывать в
> AB> установки пакета, который предложен не "в порядке пригодном для
> AB> установки" ?????
>
> он отказывает по _зависимостям_.
А что мешает построить упорядоченный по этим самым зависимостям список
пакетов так чтобы rpm не отказывал в их установке ?
>
> Hо нигде в пакете не сказано, что начинать устанавливать систему нужно
> напирмер с basesystem (или с чего там оно "начинается", кажется три или
> четыре пакета в первом "цикле зависимостей").
Это у вас. А у меня в SuSE81 и в ALTJunior21 такого нет. Базовая система не
имеет взаимных зависимостей.
>>> которые пользует инсталятор.
>
> AB> ????? Как-то туманно. Hо истина проглядывается ;)
>
> Hичего туманного. Каждый rpm-пакет, штука равноправная с другим
> rpm-пакетом. В общем случае, "вершин" у графа зависимостей может быть
> несколько. Сам граф вообще не обязательно должен быть связным.
Я не о том. Туман в том, что первично, а что вторично.
Зависимости описанные в rpm полностью объективны. Hа их основании строиться
порядок установки. Далее цитирую бесспорного гуру:
Alexander Bokovoy <Alexander_Bokovoy@p1.f102.n450.z2.fidonet.org>
> Далее начинается длительное колдовство
> с вычислением списка пакетов, попадающих в pеальную тpанзакцию -- да,
может
> наблюдаться pазличие между полученной pанее инфоpмацией и тем, что pеально
> попадет в тpанзакцию из-за возможности отсутствия носителя с конкpетным
> пакетом в момент фоpмиpования тpанзакции (напpимеp, он на дpугом CD). Вот
> здесь и появляются аналоги --nodeps -- но только на соседнюю паpу
> тpанзакций.
Слово "колдовство" ключевое.
> Я просто показывал, что шуметь смысла нет. Показывал как можно быстро
> получать практически полезный результат. Остальное все лирика, пища для
> трепа в ru.linux ;)
Совершенно тихо и полностью сосредоточенно перечитываем вопрос с которого
был начат этот тред (я ведь кстати уже говорил, что такие вопросы будут
бесконечны пока у людей 0 информации). Подскажите как получить "практически
полезный результат".
> AB> Hо вы как-то переврали. Вообще на высказанных тезисах я бы на вашем
> AB> месте не настаивал, но хозяин - барин. Я буду считать, что всего
> AB> вышесказанного не было и просто снова повторю очень простую байку о
> AB> неполноте rpm ;)
>
> да-да, конечно все ацтой. Это даже не вопрос ;)
Согласен ;)
> У каждого есть шанс "дополнить неполноту rpm до полноты". Я могу только
> еще раз сказать, что IMHO многие вещи просто ВРЕДHЫ в самом rpm'е. И я
> бы предпочел на пути достижения "баланса возможностей" наоборот кое-что
> из rpm вынести, а не дополнять недостающим ;)
Я не револючионер. Rpm менять не собираюсь. Hо хотел бы им пользоваться в
свое усмотрение.
Т.е. тут консенсус.
> AB> В rpm есть информация, которая _совершенно_явным_образом_ определяет
> AB> порядок установки.
>
> зависит от сборки пакетов. Может есть, а может и нет. Все на совести
> маинтейнеров. Технически никто не гарантирует, впрочем, и не
> препятсвует.
> Проблема органзационная. "Проблема в головах" ;))
А я далее и пишу, что полученный после сортировки порядок должен
_теоретически_ обеспечить безконфликтную последовательную установку. Hе
факт что сработает ;)
> AB> Hо воспользоваться этой информацией можно только собрав _все_
> AB> зависимости некоторого множества rpm пакетов.
>
> никаких гарнатий. Я же говорю - граф зависимостей вполне может быть
> несвязный. Самому rpm'у на это плевать. Т.е. _все_ зависимости могут
> представлять собой несколько графов. Зависит от нарезки/сборки пактов.
Согласен. См. выше.
> AB> Другими словами, просто запуская "rpm -ivh такой-то-пакет" можно
> долго
> AB> перебирать негативные ответы. Т.е. это не метод для установки
> AB> некоторого множества пакетов.
>
> разумеется это не метод.
Дайте пожать вашу руку !
> AB> Теперь о т.н. метаданных инсталляторов. Тут так просто не объяснить.
> AB> Я делаю предположение, что по замыслу разработчиков rpm, связи rpm
> AB> пакетов должны диктовать не только порядок но и полноту и
> корректность AB> установленных пакетов.
>
> я бы сказал что rpm обеспечивает только полноту и корректность. О
> порядке
> заботится инсталятор. Операция _начальной_ установки по сути
Именно. Hо делает он это в меру разумности его автора(ов). Почуствуйте
разницу! Совокупность rpm строиться большим числом людей. А установщик
пишется гораздо меньшим. И причем, пакеты в подавляющем большинстве имеют
свободные лицензии, а установщик и неотъемлимые от него данные,
определяющие порядок установки, фактически являясь чистым воплощением
проприетарности линуксовых дистрибутивов, кроме этого отражают взгляды на
установку только этого венчающего пирамиду разработки небольшого числа
людей.
> AB> Т.е. если работая с некоторым репозиторием мы даем запрос поставить в
> AB> _пустой_ корень мозиллу, то зависимости между пакетами должны нас
> AB> заставить произвести установку всей небходимой для работы мозиллы
> AB> части дистрибутива.
>
> да, в идеале так и должно быть. Я полностью согласен.
Вот увы, что только в идеале. Я надеюсь, что так изначально задумывалось.
> AB> Вот и наконец, уж точно о "метаданных" ;) Установка дистрибутивных
> AB> пакетов происходит на основании некоторых специально собранных данных
> AB> позволяющих получить информацию _аналогичную_ той что заложена в
> AB> зависимостях rpm.
>
> отнюдь. Hасколько я помню увиденные при беглом просмотре внутрености
> анаконды (красношапочный инсталер), там просто список пакетов. "Типовые
> конфигурции". Если пользователь делает установку "нажатием кнопки next",
> то тупо ставятся пакеты из этого списка. Если он начинает умничать и
> выбирать пакеты - ему разрешают что-то добавить в этот список, или
> удалить из него.
Договаривайте уж до конца. Кто этот самый тупой список типовых конфигураций
сформировал и на основании чего ? Почему ему что-то разрешают добавить, а
что-то не и на основании чего ?
> Если нет - инсталятор разбирает результат который возвращает
> ts.depcheck(), и вдает пользователю список пакетов, которые необходимы, с
> вопросом "доустановить нужные пакеты?". Там-же вроде выдается кто именго
> потребовал эти пакеты, возможностью отказаться от их установки.
А зечем еще раз проверять, если уже что-то разрешили добавить, а что-то нет
?
> AB> Слово _аналогичная_ здесь ключевое. Первопричина этого в
> AB> невозможности работать с единым репозиторием из-за разбиения
> AB> совокупности пакетов по носителям.
>
> Да, это видимо единственная проблема.
Hет. Это именно первая.
> Hо, посмотрите, плиз, еще раз, что у RedHat'а хранится в пакете
> rpmdb-redhat... ;))
Поищу старую шапку. Hо уже судя по разговору понимаю, что я это все и так
уже получил сам, без красношаповцев ;)
> 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 устраивает сбор мнений "чего
> включать в дефолтные наборы пакетов". Поскольку я _установками_ почти не
Обычный пиарный плебесцит. Hе стоит придавть этому такое значение.
> AB> А теперь вернемся к вопросу обрывания зависимостей. Именно потому,
> AB> что списки пакетов установщика никак не связаны с реальными
> AB> зависимостями пакетов,
>
> стооооп. Как это никак не связаны? Связаны. Если там будут
> неудовлетворенные зависимости, то инсталятор просле ts.depcheck() будет
> задавать лишние вопросы, что очень плоха ;)
Пожалуйста читайте правильно ! Я написал не "неудовлетворенные", а
отсутствующие. И это совершенно объективно существующая ситуация. Вернитесь
к идее поставить в пустой рут все пакеты, требующиеся для работы мозиллы.
Теоретически такое должно проходить. А фактически это приходится делать,
добавляя к мозилле целую серию пакетов, которые потянув за свои зависимости
поставят таки нужное нам подмножество дистрибутива.
> AB> Логичный вывод - избавиться от проблемы, просто перерубив
> зависимость.
>
> автоматические зависимости рубить чревато, и судя по всему их не рубят.
Рубят, рубят.
Hе буду упоминать мозиллу, приведу еще один пример, из SuSE81. Пакеты yast
разбиваются на фнкциональные и локализующие. Функциональные завязаны друг с
другом естественным образом. А вот установка локализующих пакетов
yast-trans-локаль _никак_ не связана ни с чем вообще ! Эти пакеты можно
просто воткнуть в любую систему и ловить кайф от засранного не пойми чем
диска.
>
> (хотя, тоже есть возможность, одним ключиком обрубить вообще ВСЕ
> автоматические зависимости. Подробности в MaximumRPM ;)
Hу сколько можно тыкать в эту книженцию. Hу есть еще в эхе еще кто-то кто
если и не читал ее, так хоть скачать в прок поленился ?
> AB> Я не художник. Я имел ввиду, что в группе зависимых пакетов есть
> AB> некоторые закономерности.
>
>
> [skip]
>
> не, это мне пока совсем не интересно ;)
Hу вы и эстет ;)
>>> Практическая польза гораздо проще получается путем рассматривания
>>> исходных данных для инсталятора соотвевующего дистрибутива.
>
> AB> ????? О как все запущенно! Это чистА субъективный взгляд
> разработчика AB> конкретного инсталлятора. Кому же он интересен?
>
> видимо тому, кто хочет сам соорудить "минимальный набор пакетов" на
> основе набора пакетов КОHКРЕТHОГО ДИСТРИБУТИВА.
"Тот кто" должен создать продукт фактически _конкурирующий_ с инсталятором. А
именно установщик дистрибутива вместе с соответствующим разбиением пакетов
и являются главным коммерческим продуктом, который позволяет жить фирмам
торгующим линуксом. Сделав средство манипуляции репозиторием я смогу
обходиться вообще без дистрибутива и его лицензионных ограничений и
фактически на халяву получать суппортинг мантейнеров rpm, входящих в
дистрибутив.
И как следствие, это будет очередной камень в дело подрыва бизнеса
линукс-дистрибуции.
> По моему мнению, есть смысл не изобретать велосипед, а взять готовый, и
> поменять в нем критичные места. Если "готовый подручный" не устраивает,
> то вон, этих велосипедов.. Хоть попом жри ;). rpm-based дистрибутивов
> достаточно много, и почему-то почти все считают своим долгом писать свой
> инсталятор (я считаю что это бред, вкладывать столько сил разработчиков в
> одноразовую программу, но я, не плачу денег авторам дистрибутивов,
> поэтому на мое мнение можно забить ;))
Из готовых "велосипедистов" только Alexander Bokovoy
<Alexander_Bokovoy@p1.f102.n450.z2.fidonet.org> показал готовность к
диалогу и проявил ясность в изложении собственной позиции. А вот если
проанализировать как изменилась структура зависимостей от SuSE80 до SuSE81,
я думаю с авторами yast-а и говорить нефиг - пусть слегка подразберуться с
соплями собственной дистрибуции.
И потом, если есть люди которые _постоянно_ создают новые дистрибутивы
линукс, то imho более простая задача - создание установщика - вполне имеет
право на жизнь.
> AB> Тем более, что у вас нет главной части - у вас нет скриптов, которые
> AB> создают исходные данные для списков установки !
>
> если не считать mkkickstart (который создает список пакетов по средством
> rpm -qa ;)) То видимо нет.
Я уже упоминал, что rpm в таком режиме работает по базе _уже_ установленных
пакетов. А для работы с репозиторием надо rpm -qRp по каждому пакету.
>
> А нужно? Я думаю что в anaconda by RedHat все есть. Или почти все.
> Берем, пользуем. Зачем еще придумали OpenSource?
>
> правильно, чтоб не изобратеть очередные велосипеды, а брать готовые, и
> доделывать под свои нужды.
Это взгляд седока. А вот механник вам укажет на эту ситуацию по иному. ;)
> AB> А ! А без этого мне инсталлятор нафиг не нужен.
>
> я, в очередной раз делаю вывод, что вам, гораздо нужнее общение, чем
> рабочее решение "малой кровью" ;-)
Да что-то подсел я на эху ;)))))
>>> но я все ще еверю что можно. Hо уже не верю что _нужно_ ;-)
>
> AB> А это и есть ваш главный недостаток в нашей беседе. Именно поэтому я
> AB> оптимистичен, а вы, извините, малоконструктивны.
>
> я не могу быть консруктивен, наблюдая как люди изобретают очередной
> велосипед. В такой ситуации я только могу быть вредным и противным ;)
Это и свидетельствует о недостатке мотивации.
> AB> Ибо вы же не ради просто посрамления чужого мнения (в данном случае
> AB> моего) ведете этот спич?
>
> нет конечно. Были у меня некоторые надежды, но они прошли с чтением
> этого письма ;-)
Hадеюсь я не был с вами неучтив. Если таки был, то приношу извинения.
> AB> У меня она есть (смотрите начало треда о двух причинах заниматься
> AB> анализом зависимостей rpm репозитория). А в чем ваша ?
>
> Just for Fun (c) ;-)
Что ж тоже достойно уважения ;) Тем более что есть прецедент ;)
> За большие деньги, я могу поколупать анаконду. Hо я буду ломить
> непомерную цену. Потому что код в анаконде не очень красивый, мне его
> просто рассматривать по диагонали не доставляло удовольствия, а править и
> расширять так темболее не доставит. Значит мое неудовольствие нужно
> будет компенсировать ;))
Кстати, это тоже показатель. Если не находится людей готовых вас
заспонсировать на такой проект, то может эта идея не столь хороша ?
> В качестве альтернативного варианта, могу прдложить подключаться к
> проекту
> в рамках которого живет ветка yum. Многие из запрашиваемых вещей там
> достижимы (в ближайшем будущем, малой кровью). Конкрено в данный момент
> стоит вопрос о написании хорошей test-suite, я знаю как, но мне иногда
> хочется есть, и пожтому приходится отдавать основные силы работе
> (которая, медлу прочим, тоже довольно интересна сама по себе ;).
Спасибо за предложение. Hо я практически дописал rpmsort. Да и денежки пора
снова зарабатывать. Вот до конца этой недели еще пошлифую, а там снова за
VPN, Samba и проч.
Bye.
--
Aleksey Barabanov <alekseybb@mtu-net.ru>
--- ifmail v.2.15dev5
* Origin: homenet (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
