[devel] для автоматической сборки репозитории должны выглядеть...

[Dmitry V. Levin]

On Thu, Jul 22, 2010 at 05:12:08PM +0300, Igor Vlasenko wrote:
> On Thu, Jul 22, 2010 at 05:41:52PM +0400, Dmitry V. Levin wrote:
> > > Надо этот зоопарк классифицировать, документировать,
> > > выделить и поощрять best практики. 
> > 
> > Недавно давали ссылку:
> > http://www.altlinux.org/%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0%BE_gear
> > Чем этот подход к классификации и документировании плох?
> 
> Слишком много там "диких" репозиториев приведено.

Это слишком субъективно.

> Вот, например, 
> * Репозиторий с отдельными ветками для upstream и патчей
> .gear/rules:
> tar: upstream:. name=@name@
> diff: upstream:. patches/alt/build:. name=@name на -alt-build.patch
> 
> С такими .gear/rules есть сомнения, возможна ли вообще 
> удаленная сборка по тегу. Но если и возможна, то с клона на
> http://git.altlinux.org/gears/ уже пакет собрать не получится --
> ветки upstream и patches/alt/build будут утеряны. 
> Где же воспроизводимость сборки, 
> особенно если майнтайнер свой .git сотрет?

Сборка всего, что находится в http://git.altlinux.org/gears/,
воспроизводима.  В данном примере наличие бранчей upstream и
patches/alt/build не требуется для сборки пакета, поскольку
gear-update-tag их уже зафиксировал.

> "Дикость" -- это объективное препятствие к совместной работе 
> и для робота, и для человека.

Нет, скорее субъективное, чем объективное.

> Например, если бы клон на http://git.altlinux.org/gears/
> каким то образом запоминал бы хотя бы предопределенные 
> имена ветвей (upstream, patches/*)
> то репозитарий из примера выше 1) стал бы домашним
> 2) появилась бы воспроизводимость сборки.

Если тэг собирается, то искомая информация уже была сохранена в .gears/tags/


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