Re: [devel] git submodules vs gear

["Dmitry V. Levin" <ldv@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 3745 bytes --]

On Sun, Jan 10, 2010 at 07:46:41PM +0200, Michael Shigorin wrote:
> On Sun, Jan 10, 2010 at 01:31:25AM +0300, Dmitry V. Levin wrote:
> > Now imagine that this commit id uses submodules and required external
> > commit objects are missing, because no git repository that uses
> > submodules is required to be self-contained.  In this case, gear would
> > have to attempt to fetch these commits from internet.  This is NOT
> > reliable, and gear would not be able to guarantee reproducibly.
> 
> Цитируя https://bugzilla.altlinux.org/show_bug.cgi?id=17914#c24:
> > Привнесение поддержки submodule не должно сломать эту гарантию.
> 
> Не можешь дать гарантию -- не давай.

Мне нужно, чтобы пакет воспроизводимо собирался на изолированном от
внешнего мира сервере.  Если инструмент не даёт мне такой гарантии,
то мне такой инструмент не нужен.

> Особенно если опираешься на
> услуги посредников. git когда-то давно мог гарантировать _полную_
> историю, а потом появились shallow clones и submodules (причём не
> от прихоти или "разработки ради разработки") и эта гарантия стала
> ограниченной.  Собственно, что legion@ и говорит в #c45.

shallow clones и submodules не нарушают главного свойства git -- гарантии
неизменности истории.  А то, что часть коммитов может быть оформлена таким
образом, чтобы снять обязательность локального размещения -- это не меняет
сути дела для git.  Всё таки надо понимать, что у git и gear разные
задачи.

> Цитируя #c26 и #c34:
> > Нарушается принцип достаточности коммита.
> 
> Ну и что?  Не можешь решить проблему за человека -- не мешай ему
> самому решать их, создавая непреодолимые.  "Не навреди".
> 
> А ключевые принципы, на которые опираются hasher, gear и подобные
> инструменты -- неплохо было б описывать в их документации.

Я стараюсь в меру своих сил и возможностей.

> Пока что отсутствие поддержки git submodule в сизифном gear
> противоречит его же документированной идее ("собирать пакеты
> из произвольно устроенного git-репозитория") и описанным
> ограничениям, накладываемым на структуру репозитория.

Когда был написан этот текст, git submodule не было даже в проекте.
Очевидно, текст требуется актуализировать.

> При этом упомянутый тобой принцип в ABOUT.ru.utf8 не описан --
> вскользь проскакивает во фразе "согласно которым производится
> экспорт из коммита репозитория (в форму, из которой можно
> однозначно изготовить srpm-пакет или запустить сборку)" разве.
> 
> То есть твоя позиция нарушает явно сформулированный принцип,
> даже если, как выясняется в баге с патчем, опирается на другой
> -- нигде не опубликованный до обсуждения в баге, как понимаю.

Очевидно, формулировки пора обновить, чтобы они лучше отражали реальную
картину.

> > As you see, there is a fundamental problem: GIT submodule breaks
> > repository completeness, but gear requires git repositories to be
> > self-contained.  I have no idea how to avoid this problem.
> 
> Исправить ожидания gear на соответствующие наблюдаемой
> действительности, разумеется.

Повторю ещё раз: мне нужно, чтобы gear решал вполне простую и понятную
задачу (я написал выше, какую).
> 
> Возможно, обязав заливать используемые для субмодулей репо на
> git.alt

Это не представляется возможным.

> и указывать соответствие где-нить в .gear/submodules
> во избежание тупой автоматической траты времени и трафика.
> 
> При этом технический мерж можно делать прямо перед скручиванием
> тарбола, как понимаю.  И репо чистые, и Дима доволен.

Сборочный тэг должен указывать на коммит, замыкание которого находится
в репозитории целиком и передаётся базовыми операциями (git fetch и
git push) без потерь.  Всё остальное -- детали реализации.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]