[devel] giter-factory: pkg_build_status

[Dmitry V. Levin]

On Thu, Aug 30, 2007 at 09:27:57PM +0400, Alexey Tourbin wrote:
> On Thu, Aug 30, 2007 at 08:00:43PM +0400, Dmitry V. Levin wrote:
> > On Thu, Aug 30, 2007 at 07:43:56PM +0400, Alexey Tourbin wrote:
> > > On Thu, Aug 30, 2007 at 04:07:20PM +0400, Alexey Tourbin wrote:
> > [...]
> > > > Допустим, я опубликовал perl2.git в котором нет наследования
> > > > от perl.git.  Публичного репозитария perl2.git ещё нету, поэтому
> > > > проверка наследования "для нового пакета" отключается, а собранные
> > > > пакеты perl-* просто пройдут в сизиф?
> > > 
> > > Вот решение проблемы: требовать, чтобы имя gear-репозитария в точности
> > > совпадало с именем src.rpm пакета, который получился при сборке.
> > 
> > Я предлагал к реализации немного более слабый вариант этой проверки:
> > Либо имя gear-репозитория в точности совпадает с именем spm-пакета,
> > либо отправляющий тэг на сборку явно указывает имя будущего spm-пакета.
> 
> Как будет называться публичный gear-репозитарий, в котором будет
> опубликовано сборочное дерево?  Единственный правильный вариант --
> это по названию src.rpm пакета.

По имени srpm-пакета.

> > По окончании сборки имя spm-пакета сравнивается с заявленным, и в случае
> > несовпадения результат сборки отвергается.
> 
> Тогда я не вижу, почему maintainer хочет публиковать свой приватный
> репозитарий под другим именем.  Допустим кто-то публикует питон по
> адресу perl.git.  Какой в этом смысл?  Названия публичного и приватного
> репозитариев отличается, find-package не работает.

У меня есть несколько репозиториев, из которых я собираю пакеты с разными
именами, напр. readline*, openssl* и т.п.

Т.е. причина простая: из одного репозитория собирается несколько разных
родственных пакетов.

> > > Тут получается вот какая особенность: проверить наследование коммитов
> > > можно ТОЛЬКО ПОСЛЕ ТОГО, КАК ПАКЕТ УЖЕ СОБРАЛСЯ (причем, на всех
> > > основных архитектурах).  Это противоречит нашему интуитивному
> > > представлению о том, что наследование коммитов нужно проверять
> > > до того, как собирать пакет.
> > 
> > Не вижу, что может помешать проверить git-merge-base до сборки,
> > если имя spm-пакета известно.  А оно известно до сборки по определению
> > (либо совпадает с именем gear-репозитория, либо указано явно).
> 
> А зачем его проверять до сборки?

Если что-то можно проверить ещё до сборки, то почему бы этого не сделать?
Поскольку проверка git-merge-base дешевле сборки, в этом есть смысл:
экономия ресурсов.


-- 
ldv
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20070830/1699f51d/attachment-0001.bin>