![[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
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
Всё так, но здесь немного сложнее. У вас есть libc-1.2.3 и libfoo и libbar. В списках зависимостей у libfoo и libbar стоит libc, что корректно и резолвится правильно. А теперь мы меняем libc с 1.2.3 на 1.3.0. ABI/API breakage. Надо думать что делать не столько с самой libc, сколько со всем остальным, что её хочет и что поломалось.
В убунтах мы никогда не обновляем libc с 123 до 130 в пределах релиза.
В роллингах мы бампаем и пересобираем (если у нас бинари) всё, что может поломаться.
no subject
[ все зависимости теперь жёстко контролируются и весь софт в репозитории не имеет внешних зависимостей. Т.е. ситуация, когда ты ставишь какую-либо программу, а она тебе говорит, что не хватает libfoo, потому что она вообще в каком-то другом репозтории лежит или её нет в дистрибутиве - теперь исключена" ]
У нас исходная задача - это убедиться, что у пакетов нету зависимостей вне этого репозитория. Ок, у вас есть libfoo, которой нужен libbar, которой нужен libbaz, которой нужен libfoo. Вы понимаете, что разрешение цикла здесь не входит в решение задачи "убедиться, что репозиторий замкнут сам на себя"? И что решение этой задачи никак не зависит от решения цикла?
no subject
При анализе замкнутости репозитория если попал в цикл ты должен это понять и проверить что он самодостаточен в этом репозитории.
no subject
должен? а если я проигнорирую цикл, я что не смогу понять, что репозиторий самодостаточен?
http://ideone.com/VJCQP0
no subject
--- test.py.orig 2014-08-25 13:17:30.282501285 +0300
+++ test.py 2014-08-25 13:16:51.134525778 +0300
@@ -5,8 +5,10 @@
repository = [
package('udev', ['util-linux']),
- package('util-linux', ['udev']),
- package('kde', ['qt'])
+ package('util-linux', ['udev', 'gcc']),
+ package('gcc', ['broken2']),
+ package('kde', ['qt']),
+ package('qt', ['broken'])
]
good_packages = []
===============================================================
# python test.py
good packages: ['udev', 'util-linux', 'kde']
bad packages: ['gcc', 'qt']
Разговор окончен.
no subject
У пакетов udev, util-linux и kde всё хорошо, они смотрят только внутрь репозитория.
А вот пакеты gcc и qt выбиваются из концепции замкнутого репозитория, надо ими заняться.
no subject
no subject
Найдите большого дядю из, в принципе, любого серьёзного дистрибьютива, который в этом мире не вчера родился и посмотрите что он делает, чтобы не попадать в такие ситуации.
Хуёво быть слепым сироткой, по возможности старайтесь избегать этого :)
no subject
Т.е. циклы и выстроение графа зависимостей вроде как раз входит в задачу "замкнуть все на себя".
no subject