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

[metaclass]

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

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

Comments

[d4s.livejournal.com]

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

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

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

[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: и это между прочим жуткий оффтоп ибо не имеет вообще никакого отношения к определению самодостаточности репозитория

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