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

[metaclass]

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

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

Comments

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