[devel] о репозиториях и об исходных пакетах

[Afanasov Dmitry]

On Sun, Jan 10, 2010 at 10:30:04PM +0300, Dmitry V. Levin wrote:
> On Sun, Jan 10, 2010 at 08:44:20PM +0300, Afanasov Dmitry wrote:
> > в моём представлении репозитарий является сочетанием двух множеств -
> > множества бинарных пакетов и исходников. основной чертой репозитария
> > являются зависимости, благодаря которым он приобретает свойства
> > упорядоченности и замкнутости, или связанности и направленности, если
> > воспринимать репозитарий как граф.
> > 
> > в случае с графом source rpm являются листьями.
> 
> Почему?
зависимости прописываются в каждый rpm пакет: как source, так и binary. за
исключением того, что в source rpm прописаны только requires.

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

кажется, данные о производных binary rpm даже хранятся в кеше apt'а, что
позволяет вычислить эти provides с точностью до имени srpm пакета. по
крайней мере perl'ом я их как-от выковыривал.

а значит на вопрос "почему?" я могу ответить, что это одна из моделей, где
рассматриваются только прописанные в пакете зависимости.

> Зависимости srpm-пакетов -- это функция от исходного кода и сборочной
> среды.  Такова идеология rpmbuild: сборочные зависимости вычисляются во
> время сборки.
спорил сам с собой, спорил, и пришёл к выводу, что такое определение
верно.

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

хотя если обойтись без hasher'а, то при неудовлетворенной зависимости мы
получим облом, а никакие ни вычисления, а значит это всё-таки идиология
hasher'а :)

> Таким образом, если попробовать перенести эту модель непосредственно на
> исходный код (gear-репозиторий), то для сохранения нынешнего функционала
> пришлось бы реализовать вычисление зависимостей.
да, в том числе о вычислении сборочных зависимостей конкретного gear
репозитария я и веду речь.

более того, если вспомнить первый вопрос о листьях в графе - если srpm
является листьями в графе, если мы имеем информацию о srpm в кеше апта
либо имеем целиком каталог Sisyphus, то мы можем, исходя из зависимостей,
построить граф кто из кого собрался. не имея srpm мы этот граф построить не
можем, как как наши git'ы не являются частью репозитария.

> Вопрос, зачем дублировать функционал rpmbuild?
gear и так дублирует его функционал в части сборки (упомянутый мной
rpmbuild). почему бы не продублировать в части rpmquery? :)

> > вторая причина - отсутсвие утилит. для работы rpm и source rpm есть
> > rpmquery и apt-get, для gear'а есть только "rpmbuild".
> 
> Для gear есть весь инструментарий git, hasher и rpmbuild.
> Поясните, пожалуйста, на примерах, утилиты какого рода вам нужны.
gear-query для запросов данных из spec; apt-get gear для получения gear
репозитария, откуда собран пакет; данные о gear'ах, из которых собраны
пакеты, в кеше апта; каталог gears в Sisyphus.

смех смехом, а от gear-query-requires я б действительно не отказался.
хотя да, виноват, всё руки из hasher'а выгрызть этот код не доходят.

> > я не согласен. source rpm пристуствовать обязан и он не является
> > промежуточным форматом.
> 
> Он уже сейчас фактически является промежуточным форматом.
нет, пока данных в репозитарии недостаточно для получение нужного
gear'репы, srpm не будет промежуточным форматом, а значит srpm'ы должны
быть как минимум внятно оформлены.

и если srpm не соответсвтует GPL, значит надо собирать так, чтобы
соотвествовали. либо копировать gears/ в Sisyphus/, обучать apt с ними
работать и удалять SRPMS нафиг.

и ещё учесть, что srpm весит много меньше, чем gear, содержащий 10к
srpm'ов за последние N лет.

-- 
 С уважением
 Афанасов Дмитрий
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : отсутствует
Тип     : application/pgp-signature
Размер  : 198 байтов
Описание: Digital signature
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20100111/ea973018/attachment.bin>