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

[metaclass]

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

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

Comments

[nicka-startcev.livejournal.com]

у красношляп это проблема, ибо можно привсунуть зависимость от файла, а не от (мета)пакета.

[eternal-leave.livejournal.com]

В дефолтных репах такого не видал ни разу

[eternal-leave.livejournal.com]

В стейбле дебиана нет такой фигни, в тестинге бывает.
С другой стороны, деб сильно облегчает жизнь тем, что предоставляет мягкие зависимости (позволяют в т.ч. завязать пакет на стафф извне репозитория). Говорят, в рпм они тоже есть, но их никто не видел )

[anonim-legion.livejournal.com]

В опенсорце карателей с дубинками не хватает. Поэтому, самоочевидных фич тоже нет.

[poligraph.livejournal.com]

собирал в ABF пакеты из репозитария зависимые на себя самого, т.е. как и описано в статье, что все зависимости на этапе сборки должны быть в репозитории.

[nicka-startcev.livejournal.com]

я на это нарывался примерно во времена редхат 7.1.

с тех пор предпочитаю стабильные дебианы.

[develop7]

в openSUSE (в build.opensuse.org, точнее) такого нет, потому что если зависимости не удовлетворяются — пакет просто-напросто не собирается

[d4s.livejournal.com]

гон.
вы путаете build-time и run-time зависимости.

[d4s.livejournal.com]

угу. постройте граф 15-20 тысяч пакетов со множественными связями и кольцевыми зависимостями. в каждом пакете несклько десятков бинарников со своими связями. возможно поймете масштаб проблемы.
можете на досуге подумать как выщемливать непрямые зависимости -- я про dlopen и разные врапперы в виде скриптовых программ, которые используют бинарные модули.

это только то, что на поверхности лежит. и только про классические бинарники.
добавьте джава-руби-питоны. разделите билд- и рантайм зависимости....
могу долго перечислять.

а так да, все тупые и не могут написать простейших вещей.
тут, блин, математические модели универсальные построить не могут, а вы уже имплементить хотите.

[anonim-legion.livejournal.com]

>разные врапперы в виде скриптовых программ

А не нужно.

Вот просто - если задача слишком сложная, надо ограничивать полет мысли заказчика.

[tzirechnoy.livejournal.com]

Периодически в стэйбле дебиана натыкаюсь на такую фигню.

Но, по-моему, там всегда висит баг (и у мэйнтэйнеров всегда есть веские причины, почему им лень его фиксить).

[sbj-ss.livejournal.com]

Люто, бешено поддерживаю.

[cottidianus.livejournal.com]

М, русский дистрибьютив сделал революционную разработку?



Понимаете как-бы у дистрибьютивов типа OpenSUSE таких наработок десятки (или сотни) и каждая из них интересная и заслуживает внимания. Я о них не трезвонят, они просто есть и работают.

Но русские опять доказали всему миру... и далее по тексту. Заебал давно этот пафос высосанный из пальца.

Теперь от тупого пустого пафоса к собственно фиче.

Во-первых надо ли.
В exherbo избегают образования мегарепозитория со всеми пакетами на свете. Делается это distibuted моделью: десятки мелких: официальные репозитории, репозитории девелоперов, репозитории неофициальные юзеров, репозитории неофициальные и т.п. Увидеть предупреждение пакетного манагера "для этого пакета вам нужен репозиторий reponame" и если юзер хочет репонейм, он добавляет имя репа к списку резолвентов ("install foo" превращается в "install foo repository/bar") и пакетник съедает это. В резльтате пакеты категоризированны (::kde, ::java), репозитории небольшие, Каждому кокретному юзеру врят-ли нужны все абсолютно. Так что кроссрепозиторные зависимости - добро и обыденное дело.
Во-вторых есть репозиторий ::arbor, в котором тулчейн, grub, bash, autotools и прочие фундаметнальные вещи, которые нужны просто всем. Требование к этому репозиторию (который опять же маленький из-за сильной разнесённости пакетов) - быть независимым от других репозиториев по, я думаю, очевидным причинам. И так и есть, на всю работу в ::arbor енфорсится политика независимости и он может существовать саостоятельно. Это организационный вопрос и в целом обыденное дело.
В-третьих касательно автоматизации этого дела. Когда у вас маленький репозиторий, просчитать зависимости в пределах его и найти те, которые идут за пределы репозитория - дело одного простого сёрча, который ну просто не может не уметь пакетный манагер. Опять же обыденное дело.

ЕМНИП все другие дисторибьютивы имеют мегарепозиторий с OVER9000 софта внутри (ну возьмём например центось) и в пределах этого репозитория пакеты смотрят очевидно друг на друга только. Как-бы сама мысль, что из core репозитория убунты кто-то будет просить пакет из ппа выглядит идиотской. А вот ппа могут ебать гусей, вполне очевидно.

Теперь вернёмся к русским героям-инноваторам. В чём состоит их гениальная разработка? В том, что у них в пределах core-репозитория никто не просится наружу? Ну ниибаца достижение. В том, что пакетник может пробежаться по списку пакетов и проверить, что зависимости находятся в пределах репозитория? Тоже прорыв и революция.

Очень пахнет русскоговорящим опенсоус-сообществом и его тупыми понтами. Аж воняет.

> Вроде же самоочевидная фича.
воистину

[cottidianus.livejournal.com]

щто вы несёте

Для непросвещённых: репозиторий дистрибьютива в упрощённой для нашей задачи модели выглядит как папка в которой 20К текстовых файлов с depends-списками вида
gcc.txt:
make
gettext
В среднем по 5-10 строк. В вырожденных случаях может доходить до 40. Задача: или найти все depends из всех списков, которых нет в этой папке или показать, что таких нет.

Я не думаю, что погроммиста не способного решить задачу такого уровня можно называть погроммистом.

Далее фуфло про dlopen/java/руби/питоны. Каждый питон/java/руби/we пакет в своём depends-списке имеет имена всех нужных ему пакетов. Наш audacious эксплицитно dlopen-ит модули? Оке, добавляем модули в depends. Наш чтоугодно линкуется (== имплицитно dlopen-ит) что-то? Оке, добавляем что-то в depends.
Что это поменяло для нас? Ничего.

Какие нахер математические модели универсальные. Элементарную вещь посчитать выставляется мегапроблеммой.

[wildman.livejournal.com]

тебе везёт.
я постоянно натыкался на такое с гис софтом

[d4s.livejournal.com]

Update: почитал ваше мнение веткой ниже. Боюсь, что на этом наша дискуссия закончена.

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

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

Первая ключевая ошибка, которую вы сделали -- предположили, что описания пакетов (которые, кстати, только в некоторых ветках дистров выглядят как папка с файлами) содержат всю необходимую информацию. Вторая, не менее грубая ошибка -- забыли, что репозиторий не является статическим. Третья... ай хватит.
Если вы не в состоянии осознать к чему приводят две первые проблемы, то я не готов продолжать дискуссию, начиная с азбучных вещей.

Если же осознали, то мне интересно ваше мнение по алгоритмизации разрешения кольцевых сборочных зависимостей и альтернативных провайдеров зависимостей, автоматизации бутстрапа сборочной системы и методик построения замкнутых и воспроизводимых мультиархитектурных репозиториев

[develop7]

согласен

впрочем, я при случае попробую скормить OBS runtime-зависимость от astral-utils и/или libastral.so

[jek-hor.livejournal.com]

Ну ты сейчас фигню сказал :) Смешал в кучу разрешение сложных взаимозависимостей, автоматическое определение зависимостей (это вообще на этапе сборки должно делаться) и контроль целостности графа зависимостей в репозитории пакетов.

[pascendi.livejournal.com]

Ну отчего же, они и сами признают, что это было у ALT Linux :-)

[d4s.livejournal.com]

Хех! Если бы :( В современных дистрах это все взаимосвязано :(
На этапе сборки у тебя есть начальный билд-репозиторий. И таргет-репозиторий, в который ты складываешь готовые пакеты.

И вот приплывает апдейт glibc (условно, тут может быть любая либа), который провайдит те же символы с т.з. солвера, но с измененным ABI (пропали пара экспортируемых символов) и старым сонэймом. Я даже не хочу обсуждать почему так происходит -- это просто происходит :(

С т.з. солвера это валидная замена поэтому апдейт можно вставить в таргет репозиторий, только некоторые проги гарантированно перестанут работать. Риторический вопрос -- является ли такой репозиторий целостным и лишенным внешних зависимостей? ;-)
Тут уже начинаются всяческие динамические ребилды, циклические сборочные зависимости, попытки встроить в граф зависимостей экспортируемые/импортируемы символы и прочий трэш :(
jek_hor если тебе действительно интересно, то можем на линуксовке поговорить -- там просто овердофига всякой мелочи, начиная с воспроизводимой сборочной среды и заканчивая правильным версионированием пакетов.
Еще Интегера тогда надо звать -- он моложе и память у него получше ;-)

[kostyasha.livejournal.com]

Больше всего понтуются в комментах, люди которые ничего из того что есть в любом из дистров сами не делали.
Разрозненные репозитории усложняют тестирование ввиду уникальности сочетаний выбранных репозиториев у конечного пользователя.

[sbj-ss.livejournal.com]

Давайте попробуем то ли собрать всё в кучу, то ли кучу разобрать - в общем, получить конечную постановку задачи.
По порядку:
1.1. "описания пакетов (НЕ) содержат всю необходимую информацию." Мы оперируем сборочной системой, которая имеет возможности не меньшие, чем make. Если она не может сделать информацию полной, используя явные и неявные правила - всё ли с порядке с пакетом?
1.2. "репозиторий не является статическим." Если на момент построения зависимостей репозиторий не заблокирован (не обеспечена транзакциональность), то и начинать IMHO не имеет смысла. Пошли в разрешении кольцевой зависимости за пакетом, а тот уже успел исчезнуть - что делать?
Давайте исходить из того, что на момент работы кода разрешения зависимостей есть возможность построить статический экземпляр ориентированного графа. Он (точнее, его матрица связности) представляется уместной моделью. Если так выходит, что в узлы вынужденно подставляются функции, то бишь зависимость от выбора пользователя в будущем, придётся заменить их на фиксированный набор разумных вариантов. Граф разрастётся, но останется фиксированным.
2.1 "алгоритмизации разрешения кольцевых сборочных зависимостей". Как только вы зафиксировали граф и уверены, что эту вершину вы уже обошли глубинным поиском, кольцо исчезнет - останов прохода "там мы уже были".
2.2 "альтернативных провайдеров зависимостей" - Гм. Либо провайдеры, сколько бы их ни было, предоставляют тождественную информацию, либо граф опять распухает ветвлением по провайдерам, либо кому нужны такие провайдеры, за счёт которых получается, так сказать, фрактал?
2.3 "автоматизации бутстрапа сборочной системы". Сборочная система невелика относительно дистрибутива. Если под ней рассматривать только скриптовую связку, можно и вовсе ограничиться бинарным набором под выбранную архитектуру (Gentoo тому примером). GCC? GCC может пересобраться частным порядком до сборки всего остального, пусть по максимуму. Обратная зависимость при замене glibc (вы приводили такой пример) - вопрос интересный. С большой вероятностью GCC успешно произведёт сборку и со старой glibc, остальное сделает смена симлинков. Если нет - начинается очередное разрастание графа зависимостей (появляются дополнительные параметризованные дуги, параметр - приоритет сборки). В очень наивном приближении - "не портить coreutils/binutils/xxutils".
2.4. "методик построения замкнутых и воспроизводимых мультиархитектурных репозиториев". Вроде выше я изложил соображения. Замкнутость в этой модели и является условием возможности формирования графа.
Если что - это не наезд, это моё видение, неправ - поправьте. Вы просто затронули интересный мне вопрос.

[kostyasha.livejournal.com]

Когда шел по улице споткнулся, теперь предпочитаю ходить на руках.

[kostyasha.livejournal.com]

Упрощают лишь только то что ты сможешь установить пакет в систему, а вот не гарантируют что пакет будет работать как ты ожидал. Ставь с игнорированием broken deps и получишь почти тоже самое.

[kostyasha.livejournal.com]

Нет бабла и людей желающих и способных этим заниматься, а еще нельзя сломать обратную совместимость и апдейты.