![[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
можете на досуге подумать как выщемливать непрямые зависимости -- я про dlopen и разные врапперы в виде скриптовых программ, которые используют бинарные модули.
это только то, что на поверхности лежит. и только про классические бинарники.
добавьте джава-руби-питоны. разделите билд- и рантайм зависимости....
могу долго перечислять.
а так да, все тупые и не могут написать простейших вещей.
тут, блин, математические модели универсальные построить не могут, а вы уже имплементить хотите.
no subject
А не нужно.
Вот просто - если задача слишком сложная, надо ограничивать полет мысли заказчика.
no subject
no subject
мусоргемы?no subject
no subject
2) Судя по всему ты даже не знаешь как мавен обрабатывает транзитивные зависимости
3) Твой опыт разработки очень скуден если тебе достаточно мавена.
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
Для непросвещённых: репозиторий дистрибьютива в упрощённой для нашей задачи модели выглядит как папка в которой 20К текстовых файлов с depends-списками вида
gcc.txt:
make
gettext
В среднем по 5-10 строк. В вырожденных случаях может доходить до 40. Задача: или найти все depends из всех списков, которых нет в этой папке или показать, что таких нет.
Я не думаю, что погроммиста не способного решить задачу такого уровня можно называть погроммистом.
Далее фуфло про dlopen/java/руби/питоны. Каждый питон/java/руби/we пакет в своём depends-списке имеет имена всех нужных ему пакетов. Наш audacious эксплицитно dlopen-ит модули? Оке, добавляем модули в depends. Наш чтоугодно линкуется (== имплицитно dlopen-ит) что-то? Оке, добавляем что-то в depends.
Что это поменяло для нас? Ничего.
Какие нахер математические модели универсальные. Элементарную вещь посчитать выставляется мегапроблеммой.
no subject
Уважаемый, вы сталкивались с задачами этого уровня?
могу ли я где-то посмотреть на Ваши _личные_ наработки и/или исследования в этой области?
Ваши умозрительные построения очень хороши. И пока не доходит дело до практики, то кажется, что все действительно так просто, как вы описали. Я примерно так же заблуждался. Лет этак 5-7 назад.
Первая ключевая ошибка, которую вы сделали -- предположили, что описания пакетов (которые, кстати, только в некоторых ветках дистров выглядят как папка с файлами) содержат всю необходимую информацию. Вторая, не менее грубая ошибка -- забыли, что репозиторий не является статическим. Третья... ай хватит.
Если вы не в состоянии осознать к чему приводят две первые проблемы, то я не готов продолжать дискуссию, начиная с азбучных вещей.
Если же осознали, то мне интересно ваше мнение по алгоритмизации разрешения кольцевых сборочных зависимостей и альтернативных провайдеров зависимостей, автоматизации бутстрапа сборочной системы и методик построения замкнутых и воспроизводимых мультиархитектурных репозиториев
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 заодно.
За деталями к
no subject
Несколько лет как сталкивались. И это не "уровень", это проблема организационного плана.
> могу ли я где-то посмотреть на Ваши _личные_ наработки и/или исследования в этой области?
я не вижу зачем мне это делать
> Ваши умозрительные построения очень хороши. И пока не доходит дело до практики, то кажется, что все действительно так просто, как вы описали. Я примерно так же заблуждался. Лет этак 5-7 назад.
Вы заблуждаетесь в том как оно работает, а работает оно на самом деле очень просто.
> Первая ключевая ошибка, которую вы сделали -- предположили, что описания пакетов (которые, кстати, только в некоторых ветках дистров выглядят как папка с файлами) содержат всю необходимую информацию.
Это не ошибка. Соблюдение depends-списка пакета - это гарант того, что пакет соберётся/запустится. Если список неадекватен, то это баг и он должен быть починен.
> Вторая, не менее грубая ошибка -- забыли, что репозиторий не является статическим.
Тоже не ошибка. Любой новый пакет должен удовлетворять условиям из предыдущего пункта про полноту depends-списка. Чтобы enshure это у генты есть repoman, у ексхербо есть пир ревью (кмк пир ревью даёт лучше результаты), у других дистров есть что-то другое.
В лайманских терминах: вы путаете две проблемы: замкнутость репозитория на самого себя и баги в пакетах предоставляющих неполный список. Если совсем просто, то если вы собираете phenom и линкер грохается на "не могу слинковаться с libvlc", а в build-depends в пакете нету ни слова о vlc, то у вас баг в пакете. И его надо починить. Если ваш дистрибьютив считает поломанные и неадекватные пакеты нормальным делом, то ваш дистрибьютив - помойка, а для проверки на замкнутость не достаточно информации.
> мне интересно ваше мнение по алгоритмизации разрешения кольцевых сборочных зависимостей и альтернативных провайдеров зависимостей, автоматизации бутстрапа сборочной системы и методик построения замкнутых и воспроизводимых мультиархитектурных репозиториев
Я могу рассказать, но не в формате "в жж у метакласса". Найдёте меня на конференции, подойдите, поговорим.
no subject
Короче теоретик.
(no subject)
no subject
м-м-м... на какой из? ближайшая на которой я буду -- highload. С учетом местоположения -- там еще альтовцев и из росы ребят возможно получится выцепить.
no subject
Такие простые случаи чинятся, разумеется. Собственно, они не проходят стадию сборки.
Но вот, представьте, у вас есть банальный ТеХовский пакет. В нём содержится как стилевой файл, так и документация, написанная прямо в том же TeX'е.
Для стилевого файла нужные пакеты перечисляются в преамбуле. Их можно выцарапать скриптом и поставить в Requirements. А вот что делать с документацией, которой тоже нужны какие-то пакеты?
Тут ведь проблема даже не техническая, а организационная. Раздувать пакетную базу ради 2-х файлов документации, выделяя их в отдельный пакет - texmf-pgf и texmf-pgf-doc? Или же ставить в зависимости основного пакета стилевые файлы, необходимые для сборки документации?
А кроме TeX'а есть ещё груда разных систем - Python, Ocaml, php, Tcl и т.д., у которых зависимости генерируются сложным образом, где-то решать ситуацию нужно как с TeX'ом - волевым решением.
Местами зависимости вшиты в код скриптов (скрипт, скажем, может напрямую вызывать zip/unzip или unrar), откуда их не вытащишь без полного разбора скрипта и частичного выполнения.
(no subject)
no subject
no subject
На этапе сборки у тебя есть начальный билд-репозиторий. И таргет-репозиторий, в который ты складываешь готовые пакеты.
И вот приплывает апдейт glibc (условно, тут может быть любая либа), который провайдит те же символы с т.з. солвера, но с измененным ABI (пропали пара экспортируемых символов) и старым сонэймом. Я даже не хочу обсуждать почему так происходит -- это просто происходит :(
С т.з. солвера это валидная замена поэтому апдейт можно вставить в таргет репозиторий, только некоторые проги гарантированно перестанут работать. Риторический вопрос -- является ли такой репозиторий целостным и лишенным внешних зависимостей? ;-)
Тут уже начинаются всяческие динамические ребилды, циклические сборочные зависимости, попытки встроить в граф зависимостей экспортируемые/импортируемы символы и прочий трэш :(
Еще Интегера тогда надо звать -- он моложе и память у него получше ;-)
no subject
Не валидная. API breakage должен разруливаться отпять же depends списками (за которыми в хорошем дистрибьютиве, следит меинтейнер). Для этого придумана куча решений: слоты, version-депенденсы, version срезы (например в ubuntu raring libc6 версии 2.17, 2.19 нету и не будет в раринге, но есть в trusty). Если в резолвер попал dependency resolvent по которому никак нельзя понять ломает что-то в репозитории или нет, то вы проебали где-то на этапе вбрасывания этого пакета в общий котёл. И это опять же баг и это должно быть починено. Это то с чем с момента своего создания живут роллинги типа arch, gentoo ~arch и exherbo.
> Тут уже начинаются всяческие динамические ребилды, циклические сборочные зависимости, попытки встроить в граф зависимостей экспортируемые/импортируемы символы и прочий трэш :(
Это всё дрочь бессмысленный и ирреллевантный. В резолвер попал резолвент и резолвер не может никак понять, что этот резолвент будучи установленным поломает пол системы. Это всё, это undefined behaviour, это ситуация Х в которой резолвер вообще не должен никогда очутиться. Это либо частный баг этого одного пакета, который должен быть починен, в идеале вообще не допущен. Либо резолверу предоставлено недостаточно информации для принятия правильного решения и тогда надо пересматривать политику разработки дистрибьютива в принципе.
UPD: и это между прочим жуткий оффтоп ибо не имеет вообще никакого отношения к определению самодостаточности репозитория
no subject
В принципе, поломать можно и не меняя ABI, тупо во внутренностях поменять что-нибудь (как с memcpy/memmove сломали флеш) но это уже вопрос к любителям использовать UB или к косой архитектуре внутренностей либы, если сломалось на последовательностях вызовов.
(no subject)
no subject
[ все зависимости теперь жёстко контролируются и весь софт в репозитории не имеет внешних зависимостей. Т.е. ситуация, когда ты ставишь какую-либо программу, а она тебе говорит, что не хватает libfoo, потому что она вообще в каком-то другом репозтории лежит или её нет в дистрибутиве - теперь исключена" ]
У нас исходная задача - это убедиться, что у пакетов нету зависимостей вне этого репозитория. Ок, у вас есть libfoo, которой нужен libbar, которой нужен libbaz, которой нужен libfoo. Вы понимаете, что разрешение цикла здесь не входит в решение задачи "убедиться, что репозиторий замкнут сам на себя"? И что решение этой задачи никак не зависит от решения цикла?
no subject
При анализе замкнутости репозитория если попал в цикл ты должен это понять и проверить что он самодостаточен в этом репозитории.
no subject
должен? а если я проигнорирую цикл, я что не смогу понять, что репозиторий самодостаточен?
http://ideone.com/VJCQP0
(no subject)
(no subject)
(no subject)
(no subject)
no subject
Т.е. циклы и выстроение графа зависимостей вроде как раз входит в задачу "замкнуть все на себя".
no subject