Отслеживание зависимостей пакетов при сборке дистрибутива

[metaclass]

http://ru.wikipedia.org/wiki/Rosa_Linux
http://techquisitor.livejournal.com/236159.html?thread=617599#t617599
Вычитал по ссылке такое: "Ещё одна фича сборочной системы - циклический контроль зависимостей. К выходу 2012.1 наши инженеры проделали то, что есть, пожалуй, только у ALT Linux. А именно, все зависимости теперь жёстко контролируются и весь софт в репозитории не имеет внешних зависимостей. Т.е. ситуация, когда ты ставишь какую-либо программу, а она тебе говорит, что не хватает libfoo, потому что она вообще в каком-то другом репозтории лежит или её нет в дистрибутиве - теперь исключена"

Это что, серьезно, нигде такого больше нету? Ну, в смысле, автоматом пройтись по всем пакетам и проверить, что их зависимости за пределы данного репозитория не выходят? Вроде же самоочевидная фича.

Comments

[cottidianus.livejournal.com]

> Уважаемый, вы сталкивались с задачами этого уровня?
Несколько лет как сталкивались. И это не "уровень", это проблема организационного плана.

> могу ли я где-то посмотреть на Ваши _личные_ наработки и/или исследования в этой области?
я не вижу зачем мне это делать

> Ваши умозрительные построения очень хороши. И пока не доходит дело до практики, то кажется, что все действительно так просто, как вы описали. Я примерно так же заблуждался. Лет этак 5-7 назад.
Вы заблуждаетесь в том как оно работает, а работает оно на самом деле очень просто.

> Первая ключевая ошибка, которую вы сделали -- предположили, что описания пакетов (которые, кстати, только в некоторых ветках дистров выглядят как папка с файлами) содержат всю необходимую информацию.
Это не ошибка. Соблюдение depends-списка пакета - это гарант того, что пакет соберётся/запустится. Если список неадекватен, то это баг и он должен быть починен.

> Вторая, не менее грубая ошибка -- забыли, что репозиторий не является статическим.
Тоже не ошибка. Любой новый пакет должен удовлетворять условиям из предыдущего пункта про полноту depends-списка. Чтобы enshure это у генты есть repoman, у ексхербо есть пир ревью (кмк пир ревью даёт лучше результаты), у других дистров есть что-то другое.

В лайманских терминах: вы путаете две проблемы: замкнутость репозитория на самого себя и баги в пакетах предоставляющих неполный список. Если совсем просто, то если вы собираете phenom и линкер грохается на "не могу слинковаться с libvlc", а в build-depends в пакете нету ни слова о vlc, то у вас баг в пакете. И его надо починить. Если ваш дистрибьютив считает поломанные и неадекватные пакеты нормальным делом, то ваш дистрибьютив - помойка, а для проверки на замкнутость не достаточно информации.

> мне интересно ваше мнение по алгоритмизации разрешения кольцевых сборочных зависимостей и альтернативных провайдеров зависимостей, автоматизации бутстрапа сборочной системы и методик построения замкнутых и воспроизводимых мультиархитектурных репозиториев
Я могу рассказать, но не в формате "в жж у метакласса". Найдёте меня на конференции, подойдите, поговорим.

[kostyasha.livejournal.com]

>я не вижу зачем мне это делать
Короче теоретик.

[cottidianus.livejournal.com]

короче доказывать, что не верблюд я не буду

[d4s.livejournal.com]

> Найдёте меня на конференции, подойдите, поговорим.

м-м-м... на какой из? ближайшая на которой я буду -- highload. С учетом местоположения -- там еще альтовцев и из росы ребят возможно получится выцепить.

[rdia.livejournal.com]

> Если совсем просто, то если вы собираете phenom и линкер грохается на "не могу слинковаться с libvlc", а в build-depends в пакете нету ни слова о vlc, то у вас баг в пакете. И его надо починить.

Такие простые случаи чинятся, разумеется. Собственно, они не проходят стадию сборки.

Но вот, представьте, у вас есть банальный ТеХовский пакет. В нём содержится как стилевой файл, так и документация, написанная прямо в том же TeX'е.

Для стилевого файла нужные пакеты перечисляются в преамбуле. Их можно выцарапать скриптом и поставить в Requirements. А вот что делать с документацией, которой тоже нужны какие-то пакеты?

Тут ведь проблема даже не техническая, а организационная. Раздувать пакетную базу ради 2-х файлов документации, выделяя их в отдельный пакет - texmf-pgf и texmf-pgf-doc? Или же ставить в зависимости основного пакета стилевые файлы, необходимые для сборки документации?

А кроме TeX'а есть ещё груда разных систем - Python, Ocaml, php, Tcl и т.д., у которых зависимости генерируются сложным образом, где-то решать ситуацию нужно как с TeX'ом - волевым решением.

Местами зависимости вшиты в код скриптов (скрипт, скажем, может напрямую вызывать zip/unzip или unrar), откуда их не вытащишь без полного разбора скрипта и частичного выполнения.

[cottidianus.livejournal.com]

здесь много буков, но одно и то же

Найдите дистрибьютив, который прожил в этом мире от 5 лет и посмотрите как у них принято поступать в таких ситуациях, какая политика относительно, допустим, отдельных пакетов или техов. Обычная рутина.

А так. Корректные депенды корректных версий ваших производных апстримных проектов не лежат собранные и оттестированные в INSTALL файле? А ну добро пожаловать в реальный мир. :)