[devel] Метарепозиторий Сизифа

Alexey Tourbin =?iso-8859-1?q?at_=CE=C1_altlinux=2Eru?=
Пт Ноя 9 04:06:24 MSK 2007 

On Fri, Nov 09, 2007 at 01:38:50AM +0300, Dmitry V. Levin wrote:
> > Я некоторое время назад начал делать как мне представляются подкаталоги
> > этого репозитария в giter-factory/build.gear.node.  Но есть много
> > вопросов по синхронизации архитектур и ещё кое-каких.
> Давай их сюда.

giter-factory.git.
Я там начал делать, как я себе представляю "необходимую и достаточную"
информацию о пакете, которую нужно помещать в метарепозитарий.

Вводное пояснение.  Метарепозитарий -- это репозитарий пакетов
(подкаталоги по имени src.rpm пакета), который отображает существенную
информацию о том, что происходит с пакетами в процессе эволюции
репозитария.  В частности, это зависимости пакетов, но там может быть
и кое-что ещё, вплоть до логов сборки.

Идея в том, что можно хранить основную "формальную" информацию
о пакетах в маленьких текстовых файлах, и завести для этого
git-репозитарий.  Это репозитарий должен быть достаточно хорошо
"понятен" как человеку, так и роботу.  Если maintainer'ам хочется
узнать, "что происходит с пакетами" (по зависимостям, а не в смысле
%changelog, хотя это можно и совместить, они смотрят туда.  Со временем
мы сможем сформулировать (формализовать) правила или констрейнты,
какие ситуации по зависимостям в метарепозитарии допустимы, а какие --
нет.  Формализовав наши желания достаточно хорошо, мы сможем "объяснить"
их роботу (то есть запрограммировать новые проверки на выполнение
ограничений по зависимостям), и у нас будут дополнительные гарантии
целостности репозитария, или же возможности защиты.

Всё началось с того, что был провозглашён отказ от src.rpm пакетов.
Я в то время как раз обдумывал идею тестовой пересборки сизифа на каждый
входящий пакет.  Идея эта простая: нужно у каждого src.rpm пакета взять
список BuildRequires и построить по нему замыкание.  Если в замыкание
попадают новые пакеты, src.rpm пакет подлежит тестовой пересборке.

Но при отказе от src.rpm пакетов мы НЕ ЗНАЕМ список BuildRequires.
В лучшем случае у нас есть только 1-1 соответствие между gear-репозитарием
и названием src.rpm пакета.  Чтобы узнать BuildRequires, нужно НАЧАТЬ
СОБИРАТЬ gear-репозитарий.  Этот наивный подход делает тестовую
пересборку сизифа невозможной -- нельзя никак узнать, что надо было
собирать, просто не начав сообирать всё подряд.  А это очень дорого.

Значит, нужно где-то хранить какую-то промежуточную информацию, как
минимум BuildRequires gear-репозитариев.  Здесь есть допущение,
что от сборке в разной среде BuildRequires у пакета изменяется не
слишком сильно -- на настолько сильно, что это повлияет на содержимое
сборочного чрута.  Формулировку можно уточнить, но в целом допущение
достаточно правдоподобно.  Правда, с другой стороны, src.rpm является
архитектурно-зависимым, т.е. BuildRequires нужно "кешировать" для каждой
архитектуры.

Значит, простейшая дерево метарепозитария -- это что-то типа
	.git/
	glibc/
		SVR
		i586/
			BuildRequires
		x86_64/
			BuildRequires
	bash/
		...

Поддерживая такой репозитарий в актуальном состоянии, можно по списку
новых собравшихся пакетов, сформировав временный репозитарий, за
приемлемое время узнать, какие из gear-репозитариев подлежат тестовой
пересборке.

Теперь можно нарастить подкаталоги метарепозитария зависимостями
собравшихся пакетов.
	glibc/
		SVR
		i586/
			BuildRequires
			RPMS/
				glibc-core/
					Requires
					Provides
					Conflicts
					Obsoletes
				glibc-devel/
					Requires
					Provides
					Conflicts
					Obsoletes
		x86_64/
			BuildRequires
			RPMS/
				...
	bash/
		...

Всё это неплохо гармонирует с идей тестовой пересборки сизифа.
Допустим, собрался новый glibc.  По тестовой пересборке будет
пересобран bash.  То есть обновился пакет glibc -- обновился
каталог glibc/, это "фактический" коммит (по аналогии с логами);
после этого по тестовой пересборке обновился каталог bash/,
это "тестовый коммит".  Умея отличать тестовые коммиты
от фактических, мы можем легко ответить на вопрос типа
"каким образом изменились зависимости у пакетов по тестовой
пересборке из-за нового пакета glibc" (даже если это не дало
анметов).  Это мне кажется довольно полезной информацией.

(И тем более мы сможем ответить на вопрос типа "какие пакеты перестали
собираться", если будет механизм "провести" новый glibc вручную;
можно даже там сохранить маленький кусочек лога сборки с ошибкой,
типа того что выдает beehive_status.  Логи целиком можно, наверное,
хранить отдельно.)

Есть ещё такая идея в том, что если бранч не проходит по какой-то
причине, то это причину можно хранить где-то прямо здесь же,
в метарепозитарии, в относительно формальном виде.  Например, я залил
пакет bash, и мне не хватает прав по ACL.  Тогда создается типа файл
bash/FAILED-CHECK/ACL.  Кто-то может подтвердить это как NMU
через интерфейс git.alt, сказав что-то типа
"confirm bash branch-id=<git-commit-id> my-name-is=ldv".
Тогда легко будет формально реализовать наиболее приемлемую модель NMU.
Когда приходит запрос на подтверждение NMU, giter прежде всего смотрит,
есть ли файл bash/FAILED-CHECK/ACL.  Если такой файл есть, то дальше
он проверят, есть ли у my-name-is=ldv права по пакету bash.  Если
права есть, то файл bash/FAILED-CHECK/ACL удаляется и очередная
претензия "снимается".  Когда пакет bash/FAILED-CHECK/ опустел,
тогда возможна попытка автоматичесого мёржа.

Правда вот видишь, я говорю о "МЁРЖЕ".  Мне хотелось бы, чтобы создание
файла bash/FAILED-CHECK/ACL было отдельным коммитом, и удаление этого
файла при поступлении подтверждения тоже было бы отдельным коммитам.
То есть это отображает "настоящую историю", что происходит с
репозитарием.

Кажется, при ребейсе будет труднее сделать отложенные проверки типа ACL.

Другой тип возможных проверок --
bash/FAILED-CHECK/SRPM/%name-SVR.

Это значит, что сломался чей-то другой пакет.  Значит, maintainer этого
другого пакета может, допустим, подтвердить, что новый пакет у него уже
почти готов, а старый пускай сломался.  А может и не стоит так делать.
(Давать возможность подтверждать частичный разлом, хотя это наиболее
мягкий/преемлемый вариант при допущении, что maintainer'ы ведут себя
разумно.)  Но это уже политика, кому давать а кому не давать.
С ребейсом, кажется, посложнее это будет сделать.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?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/20071109/0d1a4761/attachment-0002.bin>

Подробная информация о списке рассылки Devel