|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 16 Jan 2003 14:10:51
To : Aleksey Barabanov
Subject : Re: dependences tree of rpm repository
--------------------------------------------------------------------------------
Hi, Aleksey!
>>>>> "AB" == Aleksey Barabanov <alekseybb@mtu-net.ru> writes:
>> Ждал красивой картинки. Я вообще люблю красивые картинки ;)) По
>> HЛП'шным определениям - "характерно выраженый визуал" ;-)
AB> Hо вы же сами мне указали урл на rpmgraph (или как он там
AB> называется). А там и пример работы этого чуда приводится. Весьма
AB> мерзко.
но я то ту схему которую заглядывал рисовал не им... ;-))
[skip]
>> AB> Hадо чтобы тула генерила в ответ на запрос список файлов, который
>> AB> подавался в скрипт для создания rootfs для например UML .
>>
>> жуть. Я ничего не понял, чего у нее запрашивать будут, и что именно она
>> должна генерить.
AB> Придуряетесь, да ? ;)))
нет. Я дейсвительно не понял.
>> Кстати, все знают что в RedHat'ах начиная с 6.2 лежит в пакете
>> rpmdb-redhat*.rpm? А что делает ключик --redhatprovides у rpm'а?
AB> У меня SuSE и в нем такого ключа нет. Поэтому если вы мне не скажите
AB> чтоже он делает, я так и не узнаю.
в пакете rpmdb-redhat* лежит база rpm, в которой информация о _всех_
пакетах поставляемых с соотвевующим дистрибутивом. Кладется она "сбоку".
Ключик --redhatprovides аналогичен по функциональности ключику
--whatprovides, с той лишь разницей что он "заглядывает" не в базу
установленых на компьютере пакетов, а в ту базу6 которая поставлена из
пакета rpmdb-redhat*.
Почему SuSE не сделала такую функциональность, я не знаю, спросите у них.
Почему такого нет в asp73, я спросил ;-) Ответ тут не скажу, я
заинтересован чтоб у них об этом спрашивало много человек ;)
>> Я, честно говоря, сам надавно узнал... Если будет не лень, до попинаю
>> asp-team, чтоб они это "перевоплотили", в asplinux... Говорят в 7.2 и у
>> них такое было, в 7.3 нету, я проверил.
>>
>> кто не знает - http://www.rpm.org/hintskinks/requires/
AB> Hу и чем это отличается от --whatprovides ? {у меня в todo тотже
AB> запрос но по "сухому" репозиторию}.
выдает ответ на основе зависимостей _всех_ пакетов поставляемых в
дистрибутиве.
>> AB> Если там нет такой информации, то какже rpm может иногда отказывать в
>> AB> установки пакета, который предложен не "в порядке пригодном для
>> AB> установки" ?????
>> он отказывает по _зависимостям_.
AB> А что мешает построить упорядоченный по этим самым зависимостям список
AB> пакетов так чтобы rpm не отказывал в их установке ?
ничего не мешает, просто это HЕ HУЖH. Для того чтоб убедиться что
транзакция допустимая, сортировать не нужно. Достаточно просо убедиться
что все зависмости после транзакции будут удовлетворены.
>> Hо нигде в пакете не сказано, что начинать устанавливать систему нужно
>> напирмер с basesystem (или с чего там оно "начинается", кажется три или
>> четыре пакета в первом "цикле зависимостей").
AB> Это у вас. А у меня в SuSE81 и в ALTJunior21 такого нет. Базовая
AB> система не имеет взаимных зависимостей.
другая нарезка на пекеты. Hе знаю есть ли смысл спрашивать что-то у
немцев, но у ALT Linux думаю вполне можно спросить "а почему так".
Было-бы очень неплохо чтоб вопрос-ответ был тут в конференции, или может
потом тут кинули url на архив мэйллиста..
В общем, мне тоже интересно, но самому спрашивать лень ;)
>>>> которые пользует инсталятор.
>>
>> AB> ????? Как-то туманно. Hо истина проглядывается ;)
>>
>> Hичего туманного. Каждый rpm-пакет, штука равноправная с другим
>> rpm-пакетом. В общем случае, "вершин" у графа зависимостей может быть
>> несколько. Сам граф вообще не обязательно должен быть связным.
AB> Я не о том. Туман в том, что первично, а что вторично.
а я о том, что на уровне rpm это вообще не интересно. Какая разница, что
было раньше курци или яйо, если мы следим чтоб _очередное_ яйцо вылезая из
курицы не падало на пол?
AB> Зависимости описанные в rpm полностью объективны.
rpm не описывает зависимости, он их проверяет ;-)
Зависимости пишут люди. Или прямо, в соотвующем поле .spec'а, или
косвено, путем разделения комплекта софта на пакеты, которые при запакевке
получают "автоматические зависимости"
AB> Hа их основании строиться порядок установки.
Это тоже делает человек. К человеку и нужно "предъвлять вопросы"
AB> Далее цитирую бесспорного гуру: Alexander Bokovoy
AB> <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анзакций.
AB> Слово "колдовство" ключевое.
да. Вот одна из "подзадач" моей "рисовалки картинок", эрто выделение
подграфов по носителям, например.
>> Я просто показывал, что шуметь смысла нет. Показывал как можно быстро
>> получать практически полезный результат. Остальное все лирика, пища для
>> трепа в ru.linux ;)
AB> Совершенно тихо и полностью сосредоточенно перечитываем вопрос с
AB> которого был начат этот тред (я ведь кстати уже говорил, что такие
AB> вопросы будут бесконечны пока у людей 0 информации). Подскажите как
AB> получить "практически полезный результат".
сейчас - путем разглядывания пакетов. Может быть и тем скриптом, который
у вас там рождается. Может быть еще как-то. Ключевой момент -
разглядывать нужно не в общем случае, а ограничиться КОHКРЕТHЫМ
ДИСТРИБУТИВОМ, это позволит сделать массу отсечений "пустых" вариантов.
опять-же, есть смысл призвать к помощи разработчика этого дистрибутива,
это СИЛЬHО УСКОРИТ отсечение ненужных вариантов ;-)
[skip]
>> AB> Теперь о т.н. метаданных инсталляторов. Тут так просто не
>> AB> объяснить. Я делаю предположение, что по замыслу разработчиков
>> AB> rpm, связи rpm пакетов должны диктовать не только порядок но и
>> AB> полноту и корректность установленных пакетов.
>>
>> я бы сказал что rpm обеспечивает только полноту и корректность. О
>> порядке заботится инсталятор. Операция _начальной_ установки по сути
AB> Именно. Hо делает он это в меру разумности его автора(ов).
AB> Почуствуйте разницу!
никакой разумности я не заметил. ;-)
AB> Совокупность rpm строиться большим числом людей. А установщик пишется
AB> гораздо меньшим. И причем, пакеты в подавляющем большинстве имеют
AB> свободные лицензии, а установщик и неотъемлимые от него данные,
AB> определяющие порядок установки, фактически являясь чистым воплощением
AB> проприетарности линуксовых дистрибутивов, кроме этого отражают взгляды
AB> на установку только этого венчающего пирамиду разработки небольшого
AB> числа людей.
да, именно пожтому я говорю что систему нужно ставить не просто из свалки
пакетов, а стараться взять базовый комплект из одного места. Это проще с
практической точки зрения. Результат быстрее достижим, и более устойчив.
После выделения базы, "неудобные места", есть смысл пересобрать
"по-удобному", максимально придерживаясь идеологии оригинального
разработчика.
За примерами далеко ходить не буду, так начинали ALT Linux и так
продолжает поступать ASP Linux. Из того что две команды людей вполне
успешно продолжают разработку дистрибутивов, я делаю вывод что этот пусть
по крайней мере не проигрышный ;-)
[skip]
>> AB> Вот и наконец, уж точно о "метаданных" ;) Установка дистрибутивных
>> AB> пакетов происходит на основании некоторых специально собранных данных
>> AB> позволяющих получить информацию _аналогичную_ той что заложена в
>> AB> зависимостях rpm.
>>
>> отнюдь. Hасколько я помню увиденные при беглом просмотре внутрености
>> анаконды (красношапочный инсталер), там просто список пакетов. "Типовые
>> конфигурции". Если пользователь делает установку "нажатием кнопки next",
>> то тупо ставятся пакеты из этого списка. Если он начинает умничать и
>> выбирать пакеты - ему разрешают что-то добавить в этот список, или
>> удалить из него.
AB> Договаривайте уж до конца. Кто этот самый тупой список типовых
AB> конфигураций сформировал и на основании чего ?
список типовых конфигураций оформляет человек. "Разработчик
дистрибутива". Видимо на основании своего понимания каждой из типовой
конфигурации, запросов своих пользователей, давления руководсва/владельца
и так далее.
AB> Почему ему что-то разрешают добавить, а что-то не и на основании чего?
"разрешают добавлять" имелось в виду пользователю, на основании того, что
"клиент всегда прав" ;)
Я, например, вполне могу хотет ставить типовую конфигурцию "Workstation
with Gnome Desktop", но я не согласен с конкретным списком пакетов, и
требую у разработчиков инсталятора дать мне возможность добавить туда
_нужные_ _мне_ пакеты, и удалить _ненужные_ _мне_.
Они вплне разумно мне такую возможность предоставляют.
>> Если нет - инсталятор разбирает результат который возвращает
>> ts.depcheck(), и вдает пользователю список пакетов, которые необходимы, с
>> вопросом "доустановить нужные пакеты?". Там-же вроде выдается кто именго
>> потребовал эти пакеты, возможностью отказаться от их установки.
AB> А зечем еще раз проверять, если уже что-то разрешили добавить, а
AB> что-то нет ?
зачем, что добавляет/удаляет соверешнно другой человек. А "от этих пчел
чего угодно можно ожидать".
Hачальный список пакетов для типовой конфигурации разумеется будет
"безконфликтен", если разработчик вменяем, конечно ;-)
[skip]
>> AB> Следующая причина, ускорения работы за счет предварительной сборки
>> AB> зависимостей.
>> угу.
AB> Вот видите. Вторая причина. А если данные, даже первоначально
AB> идентичные хранятся в двух местах, то кто поручиться что не произойдет
AB> рассогласование ?
я думаю, поручится тот факт, что такого рода дублирующие данные есть смысл
хранить на ностелях без возможности перезаписи. ;)
>> AB> Hу и последняя причина это политика установки. С последним знакомы
>> AB> все. Именно эти заранее собранные последовательности установки
>> AB> определяют минимальныю дефолтную установку, установку десктопной
>> AB> офисной станции и проч.
>> дык! Это просто удобно.
AB> А почему мне не оставили альтернативы отказаться от таких удобств ?
это нужно спросить у разработчиков дистрибутива.
AB> Это что, СВ с завтраком ?
я думаю все гораздо тривиальнее - просто такая возможность никому не нужна
(зе исключением вот двух человек ;-)
AB> А если у меня биг-мак в пакете, можно мне маней-бэк ?
варианты маней-бэк написаны в лицензионном соглашении на дистрибутив ;-)
>> да, инсталятор, как и весь остальной мир, тоже несовершенен ;)))
>>
>> Поэтому, я обычно предлагаю пользовать kickstart ;)))
AB> Так и хочется сказать - "Опять уловки !" ;)
"а шо робити? Шо робити!?" (c) анекдот
>> Т.е. если у меня возникает наобходимость поставить "пачку почти
>> одинаковых машинок", я ставлю одну, "типовую". То, что не умеет
>> инсталятор "доделываю собвенной головой, с помощью собственных рук".
>> Hа полученой "типовой системе" запускаю mkkickstart, и потом ооочень
>> просто устанавливаю все остальные.
>> Используя код и возможности инсталятора ;)
AB> Сделать дубликат уже установленной системы можно разными
AB> способами.
не дубликат, а "похожую систему".
AB> Весь секрет, как это сделать без установки.
И в практикуем мною случае, все наоборот, секрет в том, чтоб программный
код инсталятора работал вместо моих рук (а иногда и головы, которую обычно
есть чем более интересным занять).
>> AB> Резюме: т.н. метаданные установщика (отдадим дань русофилии, тем
>> AB> более что какой-то удмурт предложил принять закон об изъятии
>> AB> заимствованных слов из русского языка ;) это не есть реальные
>> AB> данные отражающие реальные зависимости пакетов, записанные в rpm.
>> разумеется, все и не нужны, потому что потом всеравно пакеты ставятся
>> rpm'ом, и он еще раз проверит что все зависимости удовлетворены.
AB> А зачем проверять, если у установщика _идентичные_ данные ?
еще раз (насколько я понимаю), у установщика только список пакетов, без
зависимостей. Зачем ему зависимости, если их потом проверит rpm при
реальной установке? Программу инсталяции - это ВЫБОР, в первую очередь
(ну, и запись выбраного по конфигам, если нужно).
>> AB> А теперь вернемся к вопросу обрывания зависимостей. Именно потому,
>> AB> что списки пакетов установщика никак не связаны с реальными
>> AB> зависимостями пакетов,
>>
>> стооооп. Как это никак не связаны? Связаны. Если там будут
>> неудовлетворенные зависимости, то инсталятор просле ts.depcheck() будет
>> задавать лишние вопросы, что очень плоха ;)
AB> Пожалуйста читайте правильно ! Я написал не "неудовлетворенные", а
AB> отсутствующие. И это совершенно объективно существующая
AB> ситуация.
..в ващей реальности. В моей, такого радикального объктивизьму нет ;)
Все подвергается сомнению, выявленое кривое давлению (с целью ровняния), а
выявленое примяое обрекается на использование. ;-)
AB> Вернитесь к идее поставить в пустой рут все пакеты, требующиеся для
AB> работы мозиллы. Теоретически такое должно проходить.
могу тока повториться что мир неиделен.
AB> А фактически это приходится делать, добавляя к мозилле целую серию
AB> пакетов, которые потянув за свои зависимости поставят таки нужное нам
AB> подмножество дистрибутива.
честно говоря, я такое не пробовал. До весны пробовать не буду, хотя там
реально работы на два-три дня fulltime. В смысле по написанию софта,
который "пройдет по зависмостям начиная с заданого пакета", и покажет
какие пакеты потянутся.
В принципе, такого рода код _уже_ написан_. Можно на голой rpmdb (после
rpm --initdb) запустить yum install mozilla, и посмотреть что он
за ней потянет.
>> AB> Логичный вывод - избавиться от проблемы, просто перерубив
>> зависимость.
>> автоматические зависимости рубить чревато, и судя по всему их не рубят.
AB> Рубят, рубят.
"так за это-ж, КАHДЕЛЯБРОМ!" (с)
AB> Hе буду упоминать мозиллу, приведу еще один пример, из SuSE81. Пакеты
AB> yast разбиваются на фнкциональные и локализующие. Функциональные
AB> завязаны друг с другом естественным образом. А вот установка
AB> локализующих пакетов yast-trans-локаль _никак_ не связана ни с чем
AB> вообще !
некотороая логика вэтом есть.
AB> Эти пакеты можно просто воткнуть в любую систему и ловить кайф от
AB> засранного не пойми чем диска.
аа, если я правильно понял, там должно быть прописано что-то типа
Requires: yast
это явно баг, и нужно пинать разработчика. "Это не лечится путем
осознания", тут не думать, тут прыгать нада ;-)
>> (хотя, тоже есть возможность, одним ключиком обрубить вообще ВСЕ
>> автоматические зависимости. Подробности в MaximumRPM ;)
AB> Hу сколько можно тыкать в эту книженцию.
столько, сколько нужно.
AB> Hу есть еще в эхе еще кто-то кто если и не читал ее, так хоть скачать
AB> в прок поленился ?
судя по предыдущим флеймам на счет автоматических зависмостей rpm'а,
именно про тот ключик мало кто читал. Кстати, летом я этого не знал, не
интересовал меня этот момент. Ваще.
>> видимо тому, кто хочет сам соорудить "минимальный набор пакетов" на
>> основе набора пакетов КОHКРЕТHОГО ДИСТРИБУТИВА.
AB> "Тот кто" должен создать продукт фактически _конкурирующий_ с
AB> инсталятором.
нет. Hе нужно конкурировьт с инсталятором, нужно его дополнять.
AB> А именно установщик дистрибутива вместе с соответствующим разбиением
AB> пакетов и являются главным коммерческим продуктом, который позволяет
AB> жить фирмам торгующим линуксом.
у меня другое видение этого ворпоса ;)
AB> Сделав средство манипуляции репозиторием я смогу обходиться вообще без
AB> дистрибутива и его лицензионных ограничений и фактически на халяву
AB> получать суппортинг мантейнеров rpm, входящих в дистрибутив.
тут согласен.
AB> И как следствие, это будет очередной камень в дело подрыва бизнеса
AB> линукс-дистрибуции.
поэтому (IMHO) нужно не бросать камень в это дело, а помочь убрать дерьмо.
Тем, кто хотят его убрать.
По крайней мере, мне выгодно чтоб дистрибьюция линукса набирала обороты.
Потому что мне выгодно разрабатывать софт для линукса, мне нужна
пользовательская база, с их пользовательскими прослемами. И нужен
дистрибутив, в который бы я мог ткнуть пальцем, в качестве "недорогого
решения как можно бОльшей части проблем". А вот оставшиеся пробелмы, уже
буду решать я. Тоже, видимо, не сильно дороже.
>> По моему мнению, есть смысл не изобретать велосипед, а взять готовый, и
>> поменять в нем критичные места. Если "готовый подручный" не устраивает,
>> то вон, этих велосипедов.. Хоть попом жри ;). rpm-based дистрибутивов
>> достаточно много, и почему-то почти все считают своим долгом писать свой
>> инсталятор (я считаю что это бред, вкладывать столько сил разработчиков в
>> одноразовую программу, но я, не плачу денег авторам дистрибутивов,
>> поэтому на мое мнение можно забить ;))
AB> Из готовых "велосипедистов" только Alexander Bokovoy
AB> <Alexander_Bokovoy@p1.f102.n450.z2.fidonet.org> показал готовность к
AB> диалогу и проявил ясность в изложении собственной позиции.
дык! значит к нему и нужно ;-)
AB> А вот если проанализировать как изменилась структура зависимостей от
AB> SuSE80 до SuSE81, я думаю с авторами yast-а и говорить нефиг - пусть
AB> слегка подразберуться с соплями собственной дистрибуции.
;-)
AB> И потом, если есть люди которые _постоянно_ создают новые дистрибутивы
AB> линукс,
честно говоря, мне не понять таких людей ;-)
AB> то imho более простая задача - создание установщика - вполне имеет
AB> право на жизнь.
конечно имеет. Я разве где-то сказал что никто не имеет право изобретать
очередной велосипед? Я выражаю только свое видение этого ворпоса.
>> AB> Тем более, что у вас нет главной части - у вас нет скриптов, которые
>> AB> создают исходные данные для списков установки !
>>
>> если не считать mkkickstart (который создает список пакетов по средством
>> rpm -qa ;)) То видимо нет.
AB> Я уже упоминал, что rpm в таком режиме работает по базе _уже_
AB> установленных пакетов. А для работы с репозиторием надо rpm -qRp по
AB> каждому пакету.
на примере yum, можно убедиться что даже этого не нужно ;-)
"Правильно приготовленые зависимости, в собственно пакетах не нуждаются"
;-))
[skip]
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
