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

[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]

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

http://ideone.com/VJCQP0

[cottidianus.livejournal.com]

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

[cottidianus.livejournal.com]

> С т.з. солвера это валидная замена поэтому апдейт можно вставить в таргет репозиторий
Не валидная. API breakage должен разруливаться отпять же depends списками (за которыми в хорошем дистрибьютиве, следит меинтейнер). Для этого придумана куча решений: слоты, version-депенденсы, version срезы (например в ubuntu raring libc6 версии 2.17, 2.19 нету и не будет в раринге, но есть в trusty). Если в резолвер попал dependency resolvent по которому никак нельзя понять ломает что-то в репозитории или нет, то вы проебали где-то на этапе вбрасывания этого пакета в общий котёл. И это опять же баг и это должно быть починено. Это то с чем с момента своего создания живут роллинги типа arch, gentoo ~arch и exherbo.

> Тут уже начинаются всяческие динамические ребилды, циклические сборочные зависимости, попытки встроить в граф зависимостей экспортируемые/импортируемы символы и прочий трэш :(
Это всё дрочь бессмысленный и ирреллевантный. В резолвер попал резолвент и резолвер не может никак понять, что этот резолвент будучи установленным поломает пол системы. Это всё, это undefined behaviour, это ситуация Х в которой резолвер вообще не должен никогда очутиться. Это либо частный баг этого одного пакета, который должен быть починен, в идеале вообще не допущен. Либо резолверу предоставлено недостаточно информации для принятия правильного решения и тогда надо пересматривать политику разработки дистрибьютива в принципе.

UPD: и это между прочим жуткий оффтоп ибо не имеет вообще никакого отношения к определению самодостаточности репозитория

[kostyasha.livejournal.com]

===============================================================
--- test.py.orig 2014-08-25 13:17:30.282501285 +0300
+++ test.py 2014-08-25 13:16:51.134525778 +0300
@@ -5,8 +5,10 @@

repository = [
package('udev', ['util-linux']),
- package('util-linux', ['udev']),
- package('kde', ['qt'])
+ package('util-linux', ['udev', 'gcc']),
+ package('gcc', ['broken2']),
+ package('kde', ['qt']),
+ package('qt', ['broken'])
]

good_packages = []
===============================================================

# python test.py
good packages: ['udev', 'util-linux', 'kde']
bad packages: ['gcc', 'qt']

Разговор окончен.

[kostyasha.livejournal.com]

Зависимости как дороги - заводят не туда :)

[metaclass.livejournal.com]

Если брать репу целиком - то это обычный toposort с мелкой модификацией на тему детекта циклов.
Т.е. циклы и выстроение графа зависимостей вроде как раз входит в задачу "замкнуть все на себя".

[metaclass.livejournal.com]

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

[metaclass.livejournal.com]

Самое прямое - это тупо мыть руки после туалета. В стиле "поменяли ABI - меняем версию пакета".
В принципе, поломать можно и не меняя ABI, тупо во внутренностях поменять что-нибудь (как с memcpy/memmove сломали флеш) но это уже вопрос к любителям использовать UB или к косой архитектуре внутренностей либы, если сломалось на последовательностях вызовов.

[cottidianus.livejournal.com]

> Самое прямое - это тупо мыть руки после туалета. В стиле "поменяли ABI - меняем версию пакета".
Всё так, но здесь немного сложнее. У вас есть libc-1.2.3 и libfoo и libbar. В списках зависимостей у libfoo и libbar стоит libc, что корректно и резолвится правильно. А теперь мы меняем libc с 1.2.3 на 1.3.0. ABI/API breakage. Надо думать что делать не столько с самой libc, сколько со всем остальным, что её хочет и что поломалось.

В убунтах мы никогда не обновляем libc с 123 до 130 в пределах релиза.
В роллингах мы бампаем и пересобираем (если у нас бинари) всё, что может поломаться.

[cottidianus.livejournal.com]

всё правильно.

У пакетов udev, util-linux и kde всё хорошо, они смотрят только внутрь репозитория.
А вот пакеты gcc и qt выбиваются из концепции замкнутого репозитория, надо ими заняться.

[cottidianus.livejournal.com]

бляяяя

[d4s.livejournal.com]

1.1. в идеальном мире да -- так и есть. в реальном -- сторонние бинарные пакеты с кривыми зависимостями, баги в описаниях пакетов, баги в сборочных системах, периодическое порождение костылей "потому что надо сейчас", а на последствия плевать, либо не просчитали... Людей постоянно не хватает на сопровождение пакетов.
Насчет неявных зависимостей тоже не все так уж просто. Особенно, если они необязательны, а опциональны. Особенно если учесть весь зоопарк существующих языков и платформ.

1.2. Ну давайте предположим, что момент построения зависимостей -- ввод нового, апдейт или удаление старого пакета. Граница новой транзакции как будет определяться? А если это системообразующий пакет? А если в результате ломается не прямая связь, а через N шагов?
В модели все это проблем не представляет, а вот с пакетами все сложнее -- ресурсов для постоянно обновляемого репозитория всегда будет нехватать. Тут далеко не все сборки могут безнаказанно параллелиться и потом "мержиться" с основной веткой.
Заморозку репозитория и только баг-фикс апдейты я не рассматриваю в принципе -- там даже ручные методы управления работают.

2.1. ;-) ага. почти. здесь и далее gcc и glibc -- просто условные примеры, с ними описанные проблемы бывают крайне нечасто
Обновляем gсс, который пересобирается текущими версиями gcc и glibc, после этого пересобираем glibc обновленной версией и успокаиваемся? А потом внезапно обнаруживается, что обновленный gcc, собранный со старой версией glibc, не работает с обновленной версией.
Минимум -- 2 прохода на практике. Часто больше. Рекомендую посмотреть на поведение OBS при "правильной" сборке дистра с 0. У меня в одном из экспериментов на десктопе (i5) неделю пересобиралась урезанная до 140-150 пакетов версия федоры 12 ;-)

2.2 Все так. Это означает постоянное вмешательство человека :( В качестве примера -- тот же gcc или java. В зависимостях часто указывают gcc/java без версии, при этом пакет соберется только определеннми версиями. Бага в пакете? Да! Потиху вычищаются, но людей не хватает. А количество пакетов растет. К слову -- именно поэтому в альте постоянно обновляющийся репозиторий назвали Сизифом ;-)

2.3 ага ;) снежный ком "частных" случаев с каждым шагом все еще растет? ;-)
Любые частные случаи, зафиксированные на уровне сборочной системы потенциально аукнутся в будущем. Чтобы далеко не ходить -- "специальный" пакет в федоре для сборки мультиарча, который не покидает сборочную систему и не появляется в общем репозитории, но без которого полностью пересобрать репозиторий невозможно ;) При этом сам репозиторий, с первого взгляда, выглядит замкнутым и целостным. Это к вопросу о неявных зависимостях и ответ на 2.4 заодно.
За деталями к kostyasha

[d4s.livejournal.com]

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

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

[d4s.livejournal.com]

http://metaclass.livejournal.com/889072.html?thread=20935664#t20935664

если что -- лично нарывался с n800 вплоть до частичной неработоспособности.

[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), откуда их не вытащишь без полного разбора скрипта и частичного выполнения.

[rdia.livejournal.com]

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

[golosptic.livejournal.com]

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

[anonim-legion.livejournal.com]

Вы, наверное, знакомы с gans-spb и его творчеством.

[golosptic.livejournal.com]

не особо.
я, зато, знаком с администрированием Linux.

[cottidianus.livejournal.com]

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

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

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

[cottidianus.livejournal.com]

Два билда +- одной версии одной и той же библиотеки в системе одновременно - это обычное дело. Например я недавно упаковывал viber и делал, чтобы он юзал системный qt, вместо вбандленной копии.

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

[cottidianus.livejournal.com]

У вас комментарий чем-то похож на http://metaclass.livejournal.com/889072.html?thread=20947952#t20947952 . "А вот если мы оказались ночью, зимой, в лесу, в машине без бензина, без спичек и без тёплых ватников, ТО ЧТО ТОГДА?".

Найдите большого дядю из, в принципе, любого серьёзного дистрибьютива, который в этом мире не вчера родился и посмотрите что он делает, чтобы не попадать в такие ситуации.

Хуёво быть слепым сироткой, по возможности старайтесь избегать этого :)