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

[metaclass]

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

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

Comments

[kostyasha.livejournal.com]

Прежде чем комментить лучше бы собрал метапакет с кучей Requires: blabla зависимостей. Я это решал дублированием R в BR.

[kostyasha.livejournal.com]

Зависимость самого на себя это BR, см коммент d4s.

[d4s.livejournal.com]

Это еще фигня!
/me вспоминает разные карманы в которых оказывались по разным причинам собраны _одинаковые_ библиотеки одной и той же версии, но с разными параметрами/компиляторами/окружениями. Вот это был реальный сюрпрайз для некоторых приложений ;-) Такой себе местечковый вантуз-стайл dll hell на системном уровне ;-)

[kostyasha.livejournal.com]

У ROSA хорошие специалисты которые занимались ранее в другой конторе, а ныне в роса разработкой инструментов API/ABI checker
http://ispras.linuxbase.org/index.php/ABI_compliance_checker , upstream-tracker.org , repoclosure.
Утилита для repoclosure есть и у федоры, но они ей не пользуются на автоматизированном уровне и уровне правил/acceptance при сборке/публикации пакетов. Например по R у них просто идет периодическая проверка AFAIK. http://kostyasha.blogspot.com/2014/01/redhat-7beta-release-fail.html
Насчет openSUSE и их OBS, я кидал линки Adrian S., он сказал "интересно". Очевидно это нужно прикручивать (да и много чего другого, на мне было 20% open issues), только у кого есть время на это когда вроде как все и так работает и уже давно?

Ладно мне жалко тратить свое время. Если ты хочешь находить правильные ответы, то задавай их в правильных местах. Если реально интересно - обращайся лично, желательно вживую дабы пальцы о комп не стирать - расскажу что знаю/помню.
Если пост для кормежки троллей и чесания ЧСВ, то умываюсь.

[kostyasha.livejournal.com]

Ты же помнишь что у росы rpm5,urpmi, а у ALT перепатченный rpm4? И что да, реально надо тратить силы на написание.

Еще можно вспомнить что ALT признавал что у них нет sat solver'a, как у opensuse. (RH взял libsolv, а альты планировали писать велосипед. Не следил, чем закончилось кстати?)

[kostyasha.livejournal.com]

Так у openSUSE с их разными репами естественно будут(есть) проблемы. Логичный вывод не давать смешивать - получаем два продукта Server, Desktop (черт а ведь это уже в RH есть!). А еще с развитием виртуализаций можно будет просто нужный "диалект" в контейнере пускать :)

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

[kostyasha.livejournal.com]

Интересно? Сходи в первоисточники и разберись, хотя бы с тем что есть, а не гадай.
Даже не знаю как этот поток сознания комментировать.
1) Алгоритм сборки может быть воспроизводимым и невоспроизводимым.
2) В OBS после каждого собранного пакета все пересчитывается, алгоритм решения колец не описан, а код на перле я не осилил.
3) То как запакечено и на основе чего строится дерево. Федора/RH получают зависимости раскрывая макросы, которые связаны с окружением из которого они раскрываются что дает рекурсивную сложность. OBS библиотекой строит на основе информации спек файла и конфигурации project где эти спеки лежат.
4) Если взять тему multiarch то вы вообще забьете и будете рады тому что есть и тому как это работает.

[kostyasha.livejournal.com]

В окно смотрел? Реальность видел? Или будешь говорить про детские фантазии? Видел сколько conditional вещей внутри кода везде понаписано? А automagic dependencies? А рубимусоргемы?

[sbj-ss.livejournal.com]

Я бы предпочёл услышать мнение того, кому адресовался комментарий. Поэтому отвечу только по п.1.
Если алгоритм сборки невоспроизводим, как вы собираетесь это тестировать?

[kostyasha.livejournal.com]

Домучались, чувака порвало, сделали https://securityblog.redhat.com/2013/09/18/reproducible-builds-for-fedora/

[anonim-legion.livejournal.com]

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

[techquisitor.livejournal.com]

У нас есть и даже используем, но у нас RPM5. В RPM 4 «мягкие» зависимости только-только появились (судя по всему, Джефф таки добился своего) и войдут в выпуск RPM 4.12, если не путаю чего.

[techquisitor.livejournal.com]

Альты в рамках седьмой платформы что-то вроде даже запилили. Увижу Шигорина где — спрошу.

[cottidianus.livejournal.com]

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

[ все зависимости теперь жёстко контролируются и весь софт в репозитории не имеет внешних зависимостей. Т.е. ситуация, когда ты ставишь какую-либо программу, а она тебе говорит, что не хватает libfoo, потому что она вообще в каком-то другом репозтории лежит или её нет в дистрибутиве - теперь исключена" ]

У нас исходная задача - это убедиться, что у пакетов нету зависимостей вне этого репозитория. Ок, у вас есть libfoo, которой нужен libbar, которой нужен libbaz, которой нужен libfoo. Вы понимаете, что разрешение цикла здесь не входит в решение задачи "убедиться, что репозиторий замкнут сам на себя"? И что решение этой задачи никак не зависит от решения цикла?

[cottidianus.livejournal.com]

1.1 совершенно верно
1.2 совершенно верно
2.1 совершенно верно и очевидно
2.2 совершенно верно

[cottidianus.livejournal.com]

> Разрозненные репозитории усложняют тестирование ввиду уникальности сочетаний выбранных репозиториев у конечного пользователя.
Голословная ложь. Покажи юзкейс доказывающий это.

[prepor.livejournal.com]

Без всякой виртуализации заигрывания с rpath позволяют пускать сколько угодно версий с чем угодно.

Чем nix (http://nixos.org/nix/) давно и успешно занимается, удивлен, что в треде ни одного упоминания.

[kostyasha.livejournal.com]

1) Цикл зависимостей мавена и библиотек это просто ад.
2) Судя по всему ты даже не знаешь как мавен обрабатывает транзитивные зависимости
3) Твой опыт разработки очень скуден если тебе достаточно мавена.

[kostyasha.livejournal.com]

Видел вчера, но темы общения были другие :)

[cottidianus.livejournal.com]

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

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

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

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

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

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

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

[kostyasha.livejournal.com]

Что ты тогда имеешь ввиду под "разрешением цикла"?
При анализе замкнутости репозитория если попал в цикл ты должен это понять и проверить что он самодостаточен в этом репозитории.

[kostyasha.livejournal.com]

Они были в openSUSE. Если войдут в апстрим, то хорошо.

[techquisitor.livejournal.com]

За openSUSE не скажу, просто не в курсе. Хотя у них там много на RPM своего навешано, да. Может в самом деле не джеффовские, а сусёвые патчи взяли.

[anonim-legion.livejournal.com]

>Цикл зависимостей мавена и библиотек это просто ад.

Чуть ниже поминается код на перле. И неполная информация о зависимостях в пакетах (восхитительно). И "невоспроизводимый алгорит сборки" (это как? там совсем берега потеряли - из детерменированной системы делать случайную?)

В общем, Олдово, Инженерно, Перлово.

Те, кто это писал - SQL не знали. И математику. Зато были хорошими энергичными инженеграми, сколхозили нечто, что в принципе не может работать хорошо, теперь подпирают костылями. Молодцы, отличная job security.

[kostyasha.livejournal.com]

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