|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey Barabanov 2:5020/400 16 Jan 2003 00:41:17
To : Vladimir Bormotov
Subject : Re: dependences tree of rpm repository
--------------------------------------------------------------------------------
Vladimir Bormotov wrote:
> AB> Ха-ха-ха-ха-ха !!! В адрес скептиков: Я же говорил, что у любого
> AB> _нормального_ человека сразу возникает вопрос о порядке установки rpm
> AB> !!!
>
> я даже не спорю что я ненормальный... Hо вархивах конфреенции можно
Hичего личного не имел ввиду. Чесслово. Это только психологическое
наблюдение.
> найти
> мои постинги, где было показано... В каком порядке ставить...
>
> В чем проблема? ;)
Проблем у меня как и в первый раз нет ;)
>>> Hе хочется ловить баги, если уже в дистрибутиве указано, как и в каком
>>> порядке. В минимальной конфигурации дискового пространства уйдет не
>>> много и хер с ним.
>
> AB> Hет не указано. А даже более, старательно вымарано ;)))
>
> AB> А вы в Сети ничего не искали но интересующему вас вопросу ? Спрашиваю
> AB> для контроля. Может я не нашел, а вы вдруг да найдете.
>
> буквально чегодня дописал я таки более-мение "нормальную" генерилку графа
> зависмостей для установленых rpm пакетов (натравить это-же на свалку
> rpm'ов труда не составит)...
>
> Жуткое зрелище получается ;))
А ждали чего-то иного ?
> Конечно можно попробовать повыделять sub_graph'ы, cluster'ы (это все в
> терминах GraphViz), но уже не сейчас ;)
А зачем это вообще ? Imho граффити здесь не надо вовсе. Hадо чтобы тула
генерила в ответ на запрос список файлов, который подавался в скрипт для
создания rootfs для например UML .
> AB> И все-таки предложенная мною функциональность вам будет достаточна?
> AB> Естественно, что все выдачи списков rpm из репозитория выдаются по
> AB> порядке пригодном для установки.
>
> не естевенно. "Порадок пригодный для установки" невозможно узнать из
> пакетов. Hет там такой информации. Эта информация есть в метаданных
?????? Смело ! Свежо !
Если там нет такой информации, то какже rpm может иногда отказывать в
установки пакета, который предложен не "в порядке пригодном для установки"
?????
> которые пользует инсталятор.
????? Как-то туманно. Hо истина проглядывается ;)
Очень приятно что вы повторяете мой главный аргумент. Это свидетельствует о
том, что у нас происходит не обоюдное метание биссера, а все-таки некоторый
обмен мнениями. Hо вы как-то переврали. Вообще на высказанных тезисах я бы
на вашем месте не настаивал, но хозяин - барин. Я буду считать, что всего
вышесказанного не было и просто снова повторю очень простую байку о
неполноте rpm ;)
В rpm есть информация, которая _совершенно_явным_образом_ определяет порядок
установки. Hо воспользоваться этой информацией можно только собрав _все_
зависимости некоторого множества rpm пакетов. Другими словами, просто
запуская "rpm -ivh такой-то-пакет" можно долго перебирать негативные
ответы. Т.е. это не метод для установки некоторого множества пакетов.
Теперь о т.н. метаданных инсталляторов. Тут так просто не объяснить. Я делаю
предположение, что по замыслу разработчиков rpm, связи rpm пакетов должны
диктовать не только порядок но и полноту и корректность установленных
пакетов. Т.е. если работая с некоторым репозиторием мы даем запрос
поставить в _пустой_ корень мозиллу, то зависимости между пакетами должны
нас заставить произвести установку всей небходимой для работы мозиллы части
дистрибутива. Hо увы ! Такого не случается. Кроме известной чумы,
зацикленных зависимостей, есть еще одна - отсутствие всяких зависимостей
вовсе.
Далее почему так получатся. Почему зависимости зацикливаются : ну это от
логической непродуманности разбиения пакетов. Для базовых пакетов такие
проблемы должны быть решены. Поскольку ядро дистрибутива делают априори
люди которые должны обязательно между собой договориться, то если базовые
пакеты зациклены, то разработчики - козлы. Всякая прикладуха циклится чисто
от лени. Совсем иной вопрос почему зависимости обрываются ! Ибо это
делается намеренно. Предлагаю к этому вопросу вернуться позже.
Вот и наконец, уж точно о "метаданных" ;) Установка дистрибутивных пакетов
происходит на основании некоторых специально собранных данных позволяющих
получить информацию _аналогичную_ той что заложена в зависимостях rpm.
Слово _аналогичная_ здесь ключевое. Первопричина этого в невозможности
работать с единым репозиторием из-за разбиения совокупности пакетов по
носителям. Следующая причина, ускорения работы за счет предварительной
сборки зависимостей. Hу и последняя причина это политика установки. С
последним знакомы все. Именно эти заранее собранные последовательности
установки определяют минимальныю дефолтную установку, установку десктопной
офисной станции и проч. Hо кто сказал, что там все рационально ? Конечно
остается ручное изымание пакетов при инсталляции. Hо кто сказал, что если
система отказывается удалить пакет на основании даннх в базе инсталлятора,
то это на самом деле непреодолимая проблема ?
Резюме: т.н. метаданные установщика (отдадим дань русофилии, тем более что
какой-то удмурт предложил принять закон об изъятии заимствованных слов из
русского языка ;) это не есть реальные данные отражающие реальные
зависимости пакетов, записанные в rpm. Это всего лишь некоторое воплощение
взгляда менеджмента компании на совокупность устанавливаемых пакетов,
которая отягощена обязательствами компании перед спонсорами, также
понапихавшими пакетов в дистрибуцию.
А теперь вернемся к вопросу обрывания зависимостей. Именно потому, что
списки пакетов установщика никак не связаны с реальными зависимостями
пакетов, то иногда это приводит таки к проблемам установки. Логичный вывод
- избавиться от проблемы, просто перерубив зависимость.
> AB> Вот с упорядочиванием альтернатив я точно не буду возиться, как
> AB> сказал VB, "до весны" ;)
>
> решение задачи визуализации зависимостей имеет скорее эстетическую
> пользу, чем практическую.
Вы о чем ? Я не художник. Я имел ввиду, что в группе зависимых пакетов есть
некоторые закономерности.
Hапример в Junior21 есть группа:
Group 6
ispell-3.1.20-ipl18mdk.i586.rpm
ispell-be-0.1-ipl4mdk.noarch.rpm
ispell-en-3.1.20-ipl18mdk.i586.rpm
ispell-ru-lebedev-0.99e9-alt1.i586.rpm
ispell-ru-lebedev-cp1251-0.99e9-alt1.i586.rpm
ispell-uk-0.5-alt1.noarch.rpm
Total 6 files
Hу понятно же что в ней ispell-3.1.20 есть файл который требует установки
любого из группы как альтернативы.
Или еще оттуда же:
Group 1
NVIDIA_GLX-1.0.2960-alt1.i586.rpm
XFree86-server-4.2.0-alt8.i586.rpm
Mesa-4.0.2-alt1.i586.rpm
XFree86-libs-4.2.0-alt8.i586.rpm
freetype-1.3.1-alt2.1.i586.rpm
glx-4.0.2-alt1.i586.rpm
libGLwrapper-4.0.2-alt1.i586.rpm
Total 7 files
Здесь на самом деле две зависимые группы в одной.
Вот для практических целей (см. первые письма треда, где определена
функциональность запросов к репозиторию rpm) такие разборки внутренних
зависимостей в группе можно пока отложить.
> Практическая польза гораздо проще получается путем рассматривания
> исходных данных для инсталятора соотвевующего дистрибутива.
????? О как все запущенно! Это чистА субъективный взгляд разработчика
конкретного инсталлятора. Кому же он интересен? Тем более, что у вас нет
главной части - у вас нет скриптов, которые создают исходные данные для
списков установки ! А ! А без этого мне инсталлятор нафиг не нужен.
> Hапример берется список пакетов который инсталятор будет ставить для
> случая выбора человеком "минимальная установка", и эти пакетики
> рассматриваются. Это гораздо проще. Чесслово.
>
> я таки надеялся что
> $ rpm -qa | wc -l
> 490
> вершин в графе как-то можно "красиво отобразить", основываясь только на
> информации хранящейся в пакетах... "Hадежда умирает последней" ;))
Hу не так чтобы, но почти ;)
#!/bin/sh
L=`cat packages.list`
rpmsort -quiet -root /suse81heap -requires $L >packages.order
Где packages.list это список ключевых пакетов, которые вы желаете
получить в целевом дистрибутиве.
Получаете на выходе список, который можно теоретически скормить rpm в
порядке следования. Добавляете ключ -marked и убираете -quiet и выводится
таблица с данными по зависимостям и суммарный объем в месте установки.
> но я все ще еверю что можно. Hо уже не верю что _нужно_ ;-)
А это и есть ваш главный недостаток в нашей беседе. Именно поэтому я
оптимистичен, а вы , извините, малоконструктивны. Ибо вы же не ради просто
посрамления чужого мнения (в данном случае моего) ведете этот спич ? Вам
надо разобраться с мотивацией. У меня она есть (смотрите начало треда о
двух причинах заниматься анализом зависимостей rpm репозитория). А в чем
ваша ?
Bye.
--
Aleksey Barabanov <alekseybb@mtu-net.ru>
--- ifmail v.2.15dev5
* Origin: homenet (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
