![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Отслеживание зависимостей пакетов при сборке дистрибутива
http://ru.wikipedia.org/wiki/Rosa_Linux
http://techquisitor.livejournal.com/236159.html?thread=617599#t617599
Вычитал по ссылке такое: "Ещё одна фича сборочной системы - циклический контроль зависимостей. К выходу 2012.1 наши инженеры проделали то, что есть, пожалуй, только у ALT Linux. А именно, все зависимости теперь жёстко контролируются и весь софт в репозитории не имеет внешних зависимостей. Т.е. ситуация, когда ты ставишь какую-либо программу, а она тебе говорит, что не хватает libfoo, потому что она вообще в каком-то другом репозтории лежит или её нет в дистрибутиве - теперь исключена"
Это что, серьезно, нигде такого больше нету? Ну, в смысле, автоматом пройтись по всем пакетам и проверить, что их зависимости за пределы данного репозитория не выходят? Вроде же самоочевидная фича.
http://techquisitor.livejournal.com/236159.html?thread=617599#t617599
Вычитал по ссылке такое: "Ещё одна фича сборочной системы - циклический контроль зависимостей. К выходу 2012.1 наши инженеры проделали то, что есть, пожалуй, только у ALT Linux. А именно, все зависимости теперь жёстко контролируются и весь софт в репозитории не имеет внешних зависимостей. Т.е. ситуация, когда ты ставишь какую-либо программу, а она тебе говорит, что не хватает libfoo, потому что она вообще в каком-то другом репозтории лежит или её нет в дистрибутиве - теперь исключена"
Это что, серьезно, нигде такого больше нету? Ну, в смысле, автоматом пройтись по всем пакетам и проверить, что их зависимости за пределы данного репозитория не выходят? Вроде же самоочевидная фича.
no subject
По порядку:
1.1. "описания пакетов (НЕ) содержат всю необходимую информацию." Мы оперируем сборочной системой, которая имеет возможности не меньшие, чем make. Если она не может сделать информацию полной, используя явные и неявные правила - всё ли с порядке с пакетом?
1.2. "репозиторий не является статическим." Если на момент построения зависимостей репозиторий не заблокирован (не обеспечена транзакциональность), то и начинать IMHO не имеет смысла. Пошли в разрешении кольцевой зависимости за пакетом, а тот уже успел исчезнуть - что делать?
Давайте исходить из того, что на момент работы кода разрешения зависимостей есть возможность построить статический экземпляр ориентированного графа. Он (точнее, его матрица связности) представляется уместной моделью. Если так выходит, что в узлы вынужденно подставляются функции, то бишь зависимость от выбора пользователя в будущем, придётся заменить их на фиксированный набор разумных вариантов. Граф разрастётся, но останется фиксированным.
2.1 "алгоритмизации разрешения кольцевых сборочных зависимостей". Как только вы зафиксировали граф и уверены, что эту вершину вы уже обошли глубинным поиском, кольцо исчезнет - останов прохода "там мы уже были".
2.2 "альтернативных провайдеров зависимостей" - Гм. Либо провайдеры, сколько бы их ни было, предоставляют тождественную информацию, либо граф опять распухает ветвлением по провайдерам, либо кому нужны такие провайдеры, за счёт которых получается, так сказать, фрактал?
2.3 "автоматизации бутстрапа сборочной системы". Сборочная система невелика относительно дистрибутива. Если под ней рассматривать только скриптовую связку, можно и вовсе ограничиться бинарным набором под выбранную архитектуру (Gentoo тому примером). GCC? GCC может пересобраться частным порядком до сборки всего остального, пусть по максимуму. Обратная зависимость при замене glibc (вы приводили такой пример) - вопрос интересный. С большой вероятностью GCC успешно произведёт сборку и со старой glibc, остальное сделает смена симлинков. Если нет - начинается очередное разрастание графа зависимостей (появляются дополнительные параметризованные дуги, параметр - приоритет сборки). В очень наивном приближении - "не портить coreutils/binutils/xxutils".
2.4. "методик построения замкнутых и воспроизводимых мультиархитектурных репозиториев". Вроде выше я изложил соображения. Замкнутость в этой модели и является условием возможности формирования графа.
Если что - это не наезд, это моё видение, неправ - поправьте. Вы просто затронули интересный мне вопрос.
no subject
Даже не знаю как этот поток сознания комментировать.
1) Алгоритм сборки может быть воспроизводимым и невоспроизводимым.
2) В OBS после каждого собранного пакета все пересчитывается, алгоритм решения колец не описан, а код на перле я не осилил.
3) То как запакечено и на основе чего строится дерево. Федора/RH получают зависимости раскрывая макросы, которые связаны с окружением из которого они раскрываются что дает рекурсивную сложность. OBS библиотекой строит на основе информации спек файла и конфигурации project где эти спеки лежат.
4) Если взять тему multiarch то вы вообще забьете и будете рады тому что есть и тому как это работает.
no subject
Если алгоритм сборки невоспроизводим, как вы собираетесь это тестировать?
no subject
no subject
1.2 совершенно верно
2.1 совершенно верно и очевидно
2.2 совершенно верно
no subject
Насчет неявных зависимостей тоже не все так уж просто. Особенно, если они необязательны, а опциональны. Особенно если учесть весь зоопарк существующих языков и платформ.
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 заодно.
За деталями к