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

[metaclass]

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

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

Comments

[nicka-startcev.livejournal.com]

у красношляп это проблема, ибо можно привсунуть зависимость от файла, а не от (мета)пакета.

[eternal-leave.livejournal.com]

В дефолтных репах такого не видал ни разу

[nicka-startcev.livejournal.com]

я на это нарывался примерно во времена редхат 7.1.

с тех пор предпочитаю стабильные дебианы.

[eternal-leave.livejournal.com]

В стейбле дебиана нет такой фигни, в тестинге бывает.
С другой стороны, деб сильно облегчает жизнь тем, что предоставляет мягкие зависимости (позволяют в т.ч. завязать пакет на стафф извне репозитория). Говорят, в рпм они тоже есть, но их никто не видел )

[tzirechnoy.livejournal.com]

Периодически в стэйбле дебиана натыкаюсь на такую фигню.

Но, по-моему, там всегда висит баг (и у мэйнтэйнеров всегда есть веские причины, почему им лень его фиксить).

[wildman.livejournal.com]

тебе везёт.
я постоянно натыкался на такое с гис софтом

[kostyasha.livejournal.com]

Зависимости как дороги - заводят не туда :)

[kostyasha.livejournal.com]

Упрощают лишь только то что ты сможешь установить пакет в систему, а вот не гарантируют что пакет будет работать как ты ожидал. Ставь с игнорированием broken deps и получишь почти тоже самое.

[techquisitor.livejournal.com]

У нас есть и даже используем, но у нас RPM5. В RPM 4 «мягкие» зависимости только-только появились (судя по всему, Джефф таки добился своего) и войдут в выпуск RPM 4.12, если не путаю чего.

[kostyasha.livejournal.com]

Они были в openSUSE. Если войдут в апстрим, то хорошо.

[anonim-legion.livejournal.com]

В опенсорце карателей с дубинками не хватает. Поэтому, самоочевидных фич тоже нет.

[kostyasha.livejournal.com]

Нет бабла и людей желающих и способных этим заниматься, а еще нельзя сломать обратную совместимость и апдейты.

[poligraph.livejournal.com]

собирал в ABF пакеты из репозитария зависимые на себя самого, т.е. как и описано в статье, что все зависимости на этапе сборки должны быть в репозитории.

[kostyasha.livejournal.com]

Зависимость самого на себя это BR, см коммент d4s.

[develop7]

в openSUSE (в build.opensuse.org, точнее) такого нет, потому что если зависимости не удовлетворяются — пакет просто-напросто не собирается

[d4s.livejournal.com]

гон.
вы путаете build-time и run-time зависимости.

[d4s.livejournal.com]

угу. постройте граф 15-20 тысяч пакетов со множественными связями и кольцевыми зависимостями. в каждом пакете несклько десятков бинарников со своими связями. возможно поймете масштаб проблемы.
можете на досуге подумать как выщемливать непрямые зависимости -- я про dlopen и разные врапперы в виде скриптовых программ, которые используют бинарные модули.

это только то, что на поверхности лежит. и только про классические бинарники.
добавьте джава-руби-питоны. разделите билд- и рантайм зависимости....
могу долго перечислять.

а так да, все тупые и не могут написать простейших вещей.
тут, блин, математические модели универсальные построить не могут, а вы уже имплементить хотите.

[anonim-legion.livejournal.com]

>разные врапперы в виде скриптовых программ

А не нужно.

Вот просто - если задача слишком сложная, надо ограничивать полет мысли заказчика.

[cottidianus.livejournal.com]

щто вы несёте

Для непросвещённых: репозиторий дистрибьютива в упрощённой для нашей задачи модели выглядит как папка в которой 20К текстовых файлов с depends-списками вида
gcc.txt:
make
gettext
В среднем по 5-10 строк. В вырожденных случаях может доходить до 40. Задача: или найти все depends из всех списков, которых нет в этой папке или показать, что таких нет.

Я не думаю, что погроммиста не способного решить задачу такого уровня можно называть погроммистом.

Далее фуфло про dlopen/java/руби/питоны. Каждый питон/java/руби/we пакет в своём depends-списке имеет имена всех нужных ему пакетов. Наш audacious эксплицитно dlopen-ит модули? Оке, добавляем модули в depends. Наш чтоугодно линкуется (== имплицитно dlopen-ит) что-то? Оке, добавляем что-то в depends.
Что это поменяло для нас? Ничего.

Какие нахер математические модели универсальные. Элементарную вещь посчитать выставляется мегапроблеммой.

[jek-hor.livejournal.com]

Ну ты сейчас фигню сказал :) Смешал в кучу разрешение сложных взаимозависимостей, автоматическое определение зависимостей (это вообще на этапе сборки должно делаться) и контроль целостности графа зависимостей в репозитории пакетов.

[cottidianus.livejournal.com]

М, русский дистрибьютив сделал революционную разработку?



Понимаете как-бы у дистрибьютивов типа OpenSUSE таких наработок десятки (или сотни) и каждая из них интересная и заслуживает внимания. Я о них не трезвонят, они просто есть и работают.

Но русские опять доказали всему миру... и далее по тексту. Заебал давно этот пафос высосанный из пальца.

Теперь от тупого пустого пафоса к собственно фиче.

Во-первых надо ли.
В exherbo избегают образования мегарепозитория со всеми пакетами на свете. Делается это distibuted моделью: десятки мелких: официальные репозитории, репозитории девелоперов, репозитории неофициальные юзеров, репозитории неофициальные и т.п. Увидеть предупреждение пакетного манагера "для этого пакета вам нужен репозиторий reponame" и если юзер хочет репонейм, он добавляет имя репа к списку резолвентов ("install foo" превращается в "install foo repository/bar") и пакетник съедает это. В резльтате пакеты категоризированны (::kde, ::java), репозитории небольшие, Каждому кокретному юзеру врят-ли нужны все абсолютно. Так что кроссрепозиторные зависимости - добро и обыденное дело.
Во-вторых есть репозиторий ::arbor, в котором тулчейн, grub, bash, autotools и прочие фундаметнальные вещи, которые нужны просто всем. Требование к этому репозиторию (который опять же маленький из-за сильной разнесённости пакетов) - быть независимым от других репозиториев по, я думаю, очевидным причинам. И так и есть, на всю работу в ::arbor енфорсится политика независимости и он может существовать саостоятельно. Это организационный вопрос и в целом обыденное дело.
В-третьих касательно автоматизации этого дела. Когда у вас маленький репозиторий, просчитать зависимости в пределах его и найти те, которые идут за пределы репозитория - дело одного простого сёрча, который ну просто не может не уметь пакетный манагер. Опять же обыденное дело.

ЕМНИП все другие дисторибьютивы имеют мегарепозиторий с OVER9000 софта внутри (ну возьмём например центось) и в пределах этого репозитория пакеты смотрят очевидно друг на друга только. Как-бы сама мысль, что из core репозитория убунты кто-то будет просить пакет из ппа выглядит идиотской. А вот ппа могут ебать гусей, вполне очевидно.

Теперь вернёмся к русским героям-инноваторам. В чём состоит их гениальная разработка? В том, что у них в пределах core-репозитория никто не просится наружу? Ну ниибаца достижение. В том, что пакетник может пробежаться по списку пакетов и проверить, что зависимости находятся в пределах репозитория? Тоже прорыв и революция.

Очень пахнет русскоговорящим опенсоус-сообществом и его тупыми понтами. Аж воняет.

> Вроде же самоочевидная фича.
воистину

[kostyasha.livejournal.com]

Больше всего понтуются в комментах, люди которые ничего из того что есть в любом из дистров сами не делали.
Разрозненные репозитории усложняют тестирование ввиду уникальности сочетаний выбранных репозиториев у конечного пользователя.

[pascendi.livejournal.com]

Ну отчего же, они и сами признают, что это было у ALT Linux :-)

[kostyasha.livejournal.com]

Ты же помнишь что у росы rpm5,urpmi, а у ALT перепатченный rpm4? И что да, реально надо тратить силы на написание.

Еще можно вспомнить что ALT признавал что у них нет sat solver'a, как у opensuse. (RH взял libsolv, а альты планировали писать велосипед. Не следил, чем закончилось кстати?)

[kostyasha.livejournal.com]

У ROSA хорошие специалисты которые занимались ранее в другой конторе, а ныне в роса разработкой инструментов API/ABI checker
http://ispras.linuxbase.org/index.php/ABI_compliance_checker , upstream-tracker.org , repoclosure.
Утилита для repoclosure есть и у федоры, но они ей не пользуются на автоматизированном уровне и уровне правил/acceptance при сборке/публикации пакетов. Например по R у них просто идет периодическая проверка AFAIK. http://kostyasha.blogspot.com/2014/01/redhat-7beta-release-fail.html
Насчет openSUSE и их OBS, я кидал линки Adrian S., он сказал "интересно". Очевидно это нужно прикручивать (да и много чего другого, на мне было 20% open issues), только у кого есть время на это когда вроде как все и так работает и уже давно?

Ладно мне жалко тратить свое время. Если ты хочешь находить правильные ответы, то задавай их в правильных местах. Если реально интересно - обращайся лично, желательно вживую дабы пальцы о комп не стирать - расскажу что знаю/помню.
Если пост для кормежки троллей и чесания ЧСВ, то умываюсь.