[devel] giter-factory: pkg_build_status

[devel] giter-factory: pkg_build_status

[Alexey Tourbin]

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

Хорошо.  Будем исходить из отказа от src.rpm и большой неопределенности
на стадии запроса собрать пакет из gear.  КТО-ТО попросил собрать
КАКОЙ-ТО gear-репозитарий.  Применять ACL на данном этапе глупо,
gear-репозитарий может называться как угодно, и мы НЕ ЗНАЕМ, что
же из него в конечном счёт может собраться.  Единственный способ
это выяснить -- собрать gear-репозитарий.

Общий процесс выглядит так:

gear-request =
	gear-repo
	commit-id
	packager = invoker

	  
	     /-> build_arch i586   -> build_arch_status -\
gear-request --> build_arch x86_64 -> build_arch_status --> check_build_status -> pkg_build_status | reject
	     \-> build_arch ...    -> build_arch_status -/


Наличие pkg_build_status означает что пакет более-менее собрался,
и теперь МЫ ЗНАЕМ что именно у нас собралось.  А также мы знаем,
что именно нужно будет перекладывать в сизиф, если все последующие
проверки пойдут успешно (или если потом поступит подтверждение вручную).
Альнернативно, gear-request может получить reject.  Это означает, что
пакет либо не собрался, либо собрался "совсем плохо".

Теперь детализирую эти идеи на псведокоде.  Знак "=" касается
структур данных, знак "::" означает функцию, стрелка "->"
означает тип (сигнатуру) функции.

build_arch :: gear-request -> build_arch_status
	can_build_srpm = gear hsh --build-args=-bs
	srpm_NSVR = rpm -qp srpm
	BuildRequires = rpm -qpR srpm
	buildroot_base = hsh --initroot, hsh-shell rpm -qa
	buildroot_BR = hsh-install BuildRequires, hsh-shell rpm -qa
	buildroot_BR = buildroot_BR \setminus buildroot_base
	hasher_exit_status = gear hsh
	build_arch_status = 
		gear-request
		can_build_srpm
		srpm_NSVR
		BuildRequires
		buildroot_base
		buildroot_BR
		hasher_exit_status
		RPMS.hasher/*.rpm

check_build_status :: build_arch_status+ -> pkg_build_status | reject
	all primary arches must build (hasher_exit_status = 0 for primary_arches)
	all srpm_NSVR must be the same (map this.srpm_NSVR build_arch_status+ |sort -u |wc -l => 1)
	if at least one RPMS.hasher/*.rpm is noarch; then
		# noarch packages must build essentially the same on all arches
		# otherwise we DO NOT KNOW how to move them to sisyphus
		RPMS.hasher/*.rpm set must be the same for all arches
		rpm -qpl set must be the same for each RPMS.hasher/*.rpm for all arches
		rpm -qp --requires set must be the same for each RPMS.hasher/*.rpm for all arches
		rpm -qp --provides set must be the same for each RPMS.hasher/*.rpm for all arches, etc.
	fi
	pkg_build_status =
		pkg = srpm_NSVR
		build_arch_status+

Здесь есть такая идея, что нужно выделить primary архитектуры,
на которых ДОЛЖНО собраться, и выделить второстепенные архитектуры,
типа arm, для которых не нужно давать reject если он на ней не собрался.

Ну и вот.  Когда есть pkg_build_status, то уже можно проверять ACL
и дальше уже пускать тесты.

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

Re: [devel] giter-factory: pkg_build_status

[Alexey Tourbin]

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

On Thu, Aug 30, 2007 at 03:06:41PM +0400, Alexey Tourbin wrote:
> Хорошо.  Будем исходить из отказа от src.rpm и большой неопределенности
> на стадии запроса собрать пакет из gear.  КТО-ТО попросил собрать
> КАКОЙ-ТО gear-репозитарий.  Применять ACL на данном этапе глупо,
> gear-репозитарий может называться как угодно, и мы НЕ ЗНАЕМ, что
> же из него в конечном счёт может собраться.  Единственный способ
> это выяснить -- собрать gear-репозитарий.

Кстати, я не понял, как вы (ldv и legion) собираетесь реализовать
проверку наследования коммитов.  Проверка наследования коммитов
подразумевает, что есть публичный репозитарий с точно таким же
именем, в котором хедом является предыдущая (текущяя) сборка.
Но имя репозитария это по сути имя каталога, оно ничем не
ограничено, и нет никаких ограничений на соответствие между
именем репозитария и rpm-пакетами, которые из него собираются.

Допустим, я опубликовал perl2.git в котором нет наследования
от perl.git.  Публичного репозитария perl2.git ещё нету, поэтому
проверка наследования "для нового пакета" отключается, а собранные
пакеты perl-* просто пройдут в сизиф?

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

Re: [devel] giter-factory: pkg_build_status

[Kirill A. Shutemov]

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

On [Thu, 30.08.2007 16:07], Alexey Tourbin wrote:
> On Thu, Aug 30, 2007 at 03:06:41PM +0400, Alexey Tourbin wrote:
> > Хорошо.  Будем исходить из отказа от src.rpm и большой неопределенности
> > на стадии запроса собрать пакет из gear.  КТО-ТО попросил собрать
> > КАКОЙ-ТО gear-репозитарий.  Применять ACL на данном этапе глупо,
> > gear-репозитарий может называться как угодно, и мы НЕ ЗНАЕМ, что
> > же из него в конечном счёт может собраться.  Единственный способ
> > это выяснить -- собрать gear-репозитарий.
> 
> Кстати, я не понял, как вы (ldv и legion) собираетесь реализовать
> проверку наследования коммитов.  Проверка наследования коммитов
> подразумевает, что есть публичный репозитарий с точно таким же
> именем, в котором хедом является предыдущая (текущяя) сборка.

Зачем с точно таким же именем? 
У incoming'ера может быть свой набор git-репозиториев в которых имя
директории равно имени пакета. Получиться несколько большее количетво
репозиториев, но сборщику будет удобней.

Если приходит запрос на сборку, то смотрим какой пакет лежит в репозитории
для сборки. Если у нас уже есть репозиторий с таким именем, делаем git
pull(который fast-forward) в него. Если он не обламался -- всё ok.
Собираем.

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + Velesys LLC, http://www.velesys.com/
 + ALT Linux Team, http://www.altlinux.com/

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

Re: [devel] giter-factory: pkg_build_status

[Alexey Tourbin]

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

On Thu, Aug 30, 2007 at 03:33:51PM +0300, Kirill A. Shutemov wrote:
> Если приходит запрос на сборку, то смотрим какой пакет лежит в репозитории
> для сборки.

КАКОЙ ПАКЕТ ЛЕЖИТ В РЕПОЗИТАРИИ ДЛЯ СБОРКИ?  В условиях "высокой
неопределенности", о которой я говорю, и которая соответствует
философии hasher/gear "собирать не глядя", мы не знаем, какой
пакет лежит в репозитарии для сборки.

%if %(echo $RANDOM) < 999
Name: foo
%else
Name: bar
%endif

Скажешь не может такого быть?  А вот сделаю такой пакет и будет.
Назову его foobar.

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

Re: [devel] giter-factory: pkg_build_status

[Kirill A. Shutemov]

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

On [Thu, 30.08.2007 16:44], Alexey Tourbin wrote:
> On Thu, Aug 30, 2007 at 03:33:51PM +0300, Kirill A. Shutemov wrote:
> > Если приходит запрос на сборку, то смотрим какой пакет лежит в репозитории
> > для сборки.
> 
> КАКОЙ ПАКЕТ ЛЕЖИТ В РЕПОЗИТАРИИ ДЛЯ СБОРКИ?  В условиях "высокой
> неопределенности", о которой я говорю, и которая соответствует
> философии hasher/gear "собирать не глядя", мы не знаем, какой
> пакет лежит в репозитарии для сборки.

Похоже, обязательным становится корректность вывода gear --describe. По
крайней мере первого поля. Корректность -- отсутствие '%', т.е. отсутсвие
макросов.
Наверно, стоит допилить gear, что бы он поддерживал хак наподобии того,
что используется в ruby.git. К примеру, ввести дерективу plain-spec,
которая будет содержать name, serial, version, release(что там ещё нужно)
в плэйн-текстовом виде. И использовать его в для --describe.

> %if %(echo $RANDOM) < 999
> Name: foo
> %else
> Name: bar
> %endif
> 
> Скажешь не может такого быть?  А вот сделаю такой пакет и будет.
> Назову его foobar.

Злой ты ;)

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + Velesys LLC, http://www.velesys.com/
 + ALT Linux Team, http://www.altlinux.com/

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

Re: [devel] giter-factory: pkg_build_status

[Kirill A. Shutemov]

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

On [Thu, 30.08.2007 16:11], Kirill A. Shutemov wrote:
> On [Thu, 30.08.2007 16:44], Alexey Tourbin wrote:
> > On Thu, Aug 30, 2007 at 03:33:51PM +0300, Kirill A. Shutemov wrote:
> > > Если приходит запрос на сборку, то смотрим какой пакет лежит в репозитории
> > > для сборки.
> > 
> > КАКОЙ ПАКЕТ ЛЕЖИТ В РЕПОЗИТАРИИ ДЛЯ СБОРКИ?  В условиях "высокой
> > неопределенности", о которой я говорю, и которая соответствует
> > философии hasher/gear "собирать не глядя", мы не знаем, какой
> > пакет лежит в репозитарии для сборки.
> 
> Похоже, обязательным становится корректность вывода gear --describe. По
> крайней мере первого поля. Корректность -- отсутствие '%', т.е. отсутсвие
> макросов.
> Наверно, стоит допилить gear, что бы он поддерживал хак наподобии того,
> что используется в ruby.git. К примеру, ввести дерективу plain-spec,
> которая будет содержать name, serial, version, release(что там ещё нужно)
Я имел ввиду указывать на спек в котором вмё это будет.
> в плэйн-текстовом виде. И использовать его в для --describe.
> 
> > %if %(echo $RANDOM) < 999
> > Name: foo
> > %else
> > Name: bar
> > %endif
> > 
> > Скажешь не может такого быть?  А вот сделаю такой пакет и будет.
> > Назову его foobar.
> 
> Злой ты ;)
> 
> -- 
> Regards,  Kirill A. Shutemov
>  + Belarus, Minsk
>  + Velesys LLC, http://www.velesys.com/
>  + ALT Linux Team, http://www.altlinux.com/



> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel


-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + Velesys LLC, http://www.velesys.com/
 + ALT Linux Team, http://www.altlinux.com/

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

Re: [devel] giter-factory: pkg_build_status

[Dmitry V. Levin]

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

On Thu, Aug 30, 2007 at 04:44:44PM +0400, Alexey Tourbin wrote:
> On Thu, Aug 30, 2007 at 03:33:51PM +0300, Kirill A. Shutemov wrote:
> > Если приходит запрос на сборку, то смотрим какой пакет лежит в репозитории
> > для сборки.
> 
> КАКОЙ ПАКЕТ ЛЕЖИТ В РЕПОЗИТАРИИ ДЛЯ СБОРКИ?  В условиях "высокой
> неопределенности", о которой я говорю, и которая соответствует
> философии hasher/gear "собирать не глядя", мы не знаем, какой
> пакет лежит в репозитарии для сборки.
> 
> %if %(echo $RANDOM) < 999
> Name: foo
> %else
> Name: bar
> %endif
> 
> Скажешь не может такого быть?  А вот сделаю такой пакет и будет.
> Назову его foobar.

А что мешает делать так уже сейчас?


-- 
ldv

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

Re: [devel] giter-factory: pkg_build_status

[Alexey Tourbin]

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

On Thu, Aug 30, 2007 at 07:12:42PM +0400, Dmitry V. Levin wrote:
> On Thu, Aug 30, 2007 at 04:44:44PM +0400, Alexey Tourbin wrote:
> > On Thu, Aug 30, 2007 at 03:33:51PM +0300, Kirill A. Shutemov wrote:
> > > Если приходит запрос на сборку, то смотрим какой пакет лежит в репозитории
> > > для сборки.
> > 
> > КАКОЙ ПАКЕТ ЛЕЖИТ В РЕПОЗИТАРИИ ДЛЯ СБОРКИ?  В условиях "высокой
> > неопределенности", о которой я говорю, и которая соответствует
> > философии hasher/gear "собирать не глядя", мы не знаем, какой
> > пакет лежит в репозитарии для сборки.
> > 
> > %if %(echo $RANDOM) < 999
> > Name: foo
> > %else
> > Name: bar
> > %endif
> > 
> > Скажешь не может такого быть?  А вот сделаю такой пакет и будет.
> > Назову его foobar.
> 
> А что мешает делать так уже сейчас?

Ничто не мешает.

Сборочная система должна быть надёжной, особенно в отсутствиe человека,
который регулярно проверяет результат (перед публикацией).  Это значит,
что система должна быть устойчива к атакам, особнно к атакам типа
подмены и фальсификации.

Вот приходится выдумывать, какие могут быть атаки на фальсификацию.

Как бороться с "неопределённым" именем в Name?  Я уже предложил решение:
пакет собирается на всех архитектурах; после этого все srpm_NSVR должны
совпадать.  Несовпадение srpm_NSVR на разных архитектурах означает атаку
на фальсификацию имени пакета.

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

Re: [devel] giter-factory: pkg_build_status

[Dmitry V. Levin]

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

On Thu, Aug 30, 2007 at 07:24:27PM +0400, Alexey Tourbin wrote:
> On Thu, Aug 30, 2007 at 07:12:42PM +0400, Dmitry V. Levin wrote:
> > On Thu, Aug 30, 2007 at 04:44:44PM +0400, Alexey Tourbin wrote:
[...]
> > > Скажешь не может такого быть?  А вот сделаю такой пакет и будет.
> > > Назову его foobar.
> > 
> > А что мешает делать так уже сейчас?
> 
> Ничто не мешает.

Если пренебречь всякими provides/obsoletes, то можно предложить такую
проверку:

Проверяются права согласно имени собранного srpm-пакета.
Кроме того, для каждого собранного бинарного пакета,
если бинарный пакет с таким именем уже есть в репозитории, то
проверяются права согласно имени соответствующего ему srpm-пакета.

Поясню на примере.  Если ты отправляешь на сборку тэг, из которого
собирается srpm-пакет по имени foobar и бинарный пакет по имени
glibc-core, то результат сборки будет пропущен только если ты можешь
публиковать foobar И glibc.

> Сборочная система должна быть надёжной, особенно в отсутствиe человека,
> который регулярно проверяет результат (перед публикацией).  Это значит,
> что система должна быть устойчива к атакам, особнно к атакам типа
> подмены и фальсификации.
> 
> Вот приходится выдумывать, какие могут быть атаки на фальсификацию.

А что, давайте придумывать.

> Как бороться с "неопределённым" именем в Name?  Я уже предложил решение:
> пакет собирается на всех архитектурах; после этого все srpm_NSVR должны
> совпадать.  Несовпадение srpm_NSVR на разных архитектурах означает атаку
> на фальсификацию имени пакета.

Хорошая проверка, но не достаточная.


-- 
ldv

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

Re: [devel] giter-factory: pkg_build_status

[Kirill A. Shutemov]

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

On [Thu, 30.08.2007 19:54], Dmitry V. Levin wrote:
> On Thu, Aug 30, 2007 at 07:24:27PM +0400, Alexey Tourbin wrote:
> > On Thu, Aug 30, 2007 at 07:12:42PM +0400, Dmitry V. Levin wrote:
> > > On Thu, Aug 30, 2007 at 04:44:44PM +0400, Alexey Tourbin wrote:
> [...]
> > > > Скажешь не может такого быть?  А вот сделаю такой пакет и будет.
> > > > Назову его foobar.
> > > 
> > > А что мешает делать так уже сейчас?
> > 
> > Ничто не мешает.
> 
> Если пренебречь всякими provides/obsoletes, то можно предложить такую
> проверку:
> 
> Проверяются права согласно имени собранного srpm-пакета.

Т.е проверку на то что собираемый коммит наследуется от прошлого собраного
делать только послесборки srpm'а? Не слишком ли дорого?

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + Velesys LLC, http://www.velesys.com/
 + ALT Linux Team, http://www.altlinux.com/

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

Re: [devel] giter-factory: pkg_build_status

[Dmitry V. Levin]

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

On Thu, Aug 30, 2007 at 07:04:59PM +0300, Kirill A. Shutemov wrote:
> On [Thu, 30.08.2007 19:54], Dmitry V. Levin wrote:
> > On Thu, Aug 30, 2007 at 07:24:27PM +0400, Alexey Tourbin wrote:
> > > On Thu, Aug 30, 2007 at 07:12:42PM +0400, Dmitry V. Levin wrote:
> > > > On Thu, Aug 30, 2007 at 04:44:44PM +0400, Alexey Tourbin wrote:
> > [...]
> > > > > Скажешь не может такого быть?  А вот сделаю такой пакет и будет.
> > > > > Назову его foobar.
> > > > 
> > > > А что мешает делать так уже сейчас?
> > > 
> > > Ничто не мешает.
> > 
> > Если пренебречь всякими provides/obsoletes, то можно предложить такую
> > проверку:
> > 
> > Проверяются права согласно имени собранного srpm-пакета.
> 
> Т.е проверку на то что собираемый коммит наследуется от прошлого собраного
> делать только послесборки srpm'а? Не слишком ли дорого?

Кое-кто недочитал написанное. ;)

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


-- 
ldv

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

Re: [devel] giter-factory: pkg_build_status

[Alexey Tourbin]

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

On Thu, Aug 30, 2007 at 07:04:59PM +0300, Kirill A. Shutemov wrote:
> > Проверяются права согласно имени собранного srpm-пакета.
> 
> Т.е проверку на то что собираемый коммит наследуется от прошлого собраного
> делать только послесборки srpm'а? Не слишком ли дорого?

Про дороговизну отдельного случая, если он возникает,
не имеет смысла говорить.  См. мои опусы насчет статистики.

То есть это будет слишком дорого, если будут делать слишком часто
запросы на сборку, такие что требования наследования в этих запросах
не соблюдается.  Я всё же не думаю, что такие запросы будут появляться
слишком часто.

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

Re: [devel] giter-factory: pkg_build_status

[Alexey Tourbin]

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

On Thu, Aug 30, 2007 at 07:54:19PM +0400, Dmitry V. Levin wrote:
> Если пренебречь всякими provides/obsoletes, то можно предложить такую
> проверку:

Ими нельзя пренебрегать.  Кто-то обязательно напишет
Provdies: coreutils, Obsoletes: coreutils.

> Проверяются права согласно имени собранного srpm-пакета.
> Кроме того, для каждого собранного бинарного пакета,
> если бинарный пакет с таким именем уже есть в репозитории, то
> проверяются права согласно имени соответствующего ему srpm-пакета.
> 
> Поясню на примере.  Если ты отправляешь на сборку тэг, из которого
> собирается srpm-пакет по имени foobar и бинарный пакет по имени
> glibc-core, то результат сборки будет пропущен только если ты можешь
> публиковать foobar И glibc.

Я об этом тоже думал.  Это уже следующий этап -- формирование временного
сизифа и проверка, удаётся ли "прописать" новые пакеты в этот временный
сизиф без "конфликтов".

Но сейчас у нас предыдущая задача: определить, собрался пакет или не
собрался, и собрался ли он достаточно хорошо, а то надо сразу давать
ему reject.  Конекст этой задачи по пакетам ограничен содержимым
билдурта при сборке.  По сути мы пока не знаем, в какой репозитарий
собранные пакеты придётся "прописывать".  Сейчас пока нужно выяснить,
собирается ли пакет САМ ПО СЕБЕ, и является ли результат в принципе
публикуемым (наследование коммитов, синхронизация архитектур,
идентичность noarch пакетов).

Что до проверки ACL, то её можно делать раньше или позже.  Более того,
нет ничего плохого в том, чтобы делать её немного попозже.  Ведь любой
пакет, который не проходит ACL, является потенциальным NMU.  Значит, у
нас получается "цимесная" модель NMU вместо старой "отстойной".  Можно
будет выдавать NUM per commit и только per-commit, то есть
"подтверждать" NMU с предварительной проверкой.  Думаю, что правом
подтверждения NMU можно наделить и "ответственного товарища", поскольку
часто речь идёт о NMU типа "rebuild with libxxx.so.2".

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

Re: [devel] giter-factory: pkg_build_status

[Alexey Tourbin]

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

On Thu, Aug 30, 2007 at 04:07:20PM +0400, Alexey Tourbin wrote:
> On Thu, Aug 30, 2007 at 03:06:41PM +0400, Alexey Tourbin wrote:
> > Хорошо.  Будем исходить из отказа от src.rpm и большой неопределенности
> > на стадии запроса собрать пакет из gear.  КТО-ТО попросил собрать
> > КАКОЙ-ТО gear-репозитарий.  Применять ACL на данном этапе глупо,
> > gear-репозитарий может называться как угодно, и мы НЕ ЗНАЕМ, что
> > же из него в конечном счёт может собраться.  Единственный способ
> > это выяснить -- собрать gear-репозитарий.
> 
> Кстати, я не понял, как вы (ldv и legion) собираетесь реализовать
> проверку наследования коммитов.  Проверка наследования коммитов
> подразумевает, что есть публичный репозитарий с точно таким же
> именем, в котором хедом является предыдущая (текущяя) сборка.
> Но имя репозитария это по сути имя каталога, оно ничем не
> ограничено, и нет никаких ограничений на соответствие между
> именем репозитария и rpm-пакетами, которые из него собираются.
> 
> Допустим, я опубликовал perl2.git в котором нет наследования
> от perl.git.  Публичного репозитария perl2.git ещё нету, поэтому
> проверка наследования "для нового пакета" отключается, а собранные
> пакеты perl-* просто пройдут в сизиф?

Вот решение проблемы: требовать, чтобы имя gear-репозитария в точности
совпадало с именем src.rpm пакета, который получился при сборке.

--- pkg_build_status.txt-	2007-08-30 15:30:38 +0000
+++ pkg_build_status.txt	2007-08-30 15:34:17 +0000
@@ -24,6 +24,10 @@
 check_build_status :: build_arch_status+ -> pkg_build_status | reject
 	all primary arches must build (hasher_exit_status = 0 for primary_arches)
 	all srpm_NSVR must be the same (map this.srpm_NSVR build_arch_status+ |sort -u |wc -l => 1)
+	require that $(basename gear-request.gear-repo .git) exactly matches srpm_NSVR.name
+	if has public gear-request.gear-repo; then
+		check commit ancestry $(public gear-repo) gear-request.commit-id
+	fi
 	if at least one RPMS.hasher/*.rpm is noarch; then
 		# noarch packages must build essentially the same on all arches
 		# otherwise we DO NOT KNOW how to move them to sisyphus

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

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

Ну противоречит и ладно.  Не вижу в этом большой проблемы.
Квантовая механика тоже противоречит инуитивным представлениям,
причем неким похожим образом -- "нельзя узнать раньше времени,
пока оно таки не случится".
http://en.wikipedia.org/wiki/Wavefunction_collapse
http://en.wikipedia.org/wiki/Double-slit_experiment

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

Re: [devel] giter-factory: pkg_build_status

[Dmitry V. Levin]

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

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-пакета.
По окончании сборки имя spm-пакета сравнивается с заявленным, и в случае
несовпадения результат сборки отвергается.

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

Не вижу, что может помешать проверить git-merge-base до сборки,
если имя spm-пакета известно.  А оно известно до сборки по определению
(либо совпадает с именем gear-репозитория, либо указано явно).


-- 
ldv

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

Re: [devel] giter-factory: pkg_build_status

[Alexey Tourbin]

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

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 пакета.

> По окончании сборки имя spm-пакета сравнивается с заявленным, и в случае
> несовпадения результат сборки отвергается.

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

Впрочем, у меня есть такой репозитарий: cairo.git, а src.rpm пакет
называется libcairo.  Но я думаю что просто нужно переименовать src.rpm
пакет в cairo.  Во всяком случае, я не хотел бы, чтобы в публичном
репозитарии публиковался libcairo.git, а у меня лежал cairo.git.

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

А зачем его проверять до сборки?  Я же говорю, это только то,
что нам кажется привычно.  Если проверка будет срабатывать позже,
то это непривычно, но она всё равно будет срабатывать.

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

Re: [devel] giter-factory: pkg_build_status

[Dmitry V. Levin]

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

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

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

Re: [devel] giter-factory: pkg_build_status

[Alexey Tourbin]

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

On Thu, Aug 30, 2007 at 09:40:41PM +0400, Dmitry V. Levin wrote:
> > > По окончании сборки имя spm-пакета сравнивается с заявленным, и в случае
> > > несовпадения результат сборки отвергается.
> > 
> > Тогда я не вижу, почему maintainer хочет публиковать свой приватный
> > репозитарий под другим именем.  Допустим кто-то публикует питон по
> > адресу perl.git.  Какой в этом смысл?  Названия публичного и приватного
> > репозитариев отличается, find-package не работает.
> 
> У меня есть несколько репозиториев, из которых я собираю пакеты с разными
> именами, напр. readline*, openssl* и т.п.
> 
> Т.е. причина простая: из одного репозитория собирается несколько разных
> родственных пакетов.

То есть у тебя лежит всего один readline.git, а в публичном хранилище
будет публиковаться несколько readline*.git репозитариев?  Хм, некузяво.
Хотелось бы достичь 1-1 соответствия между именами публичных и приватных
репозитариев.

А то точно кто-нибудь будет публиковать питон по адресу perl.git. :)

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

Отчасти так, хотя экономия ресурсов не обещает быть заметной, если
только уважаемые товарищи maintainer'ы не устроят флешмоба "пошли на
сборку запрос который не наследует от предыдущей сборки".

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

Re: [devel] giter-factory: pkg_build_status

[Dmitry V. Levin]

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

On Thu, Aug 30, 2007 at 09:50:13PM +0400, Alexey Tourbin wrote:
> On Thu, Aug 30, 2007 at 09:40:41PM +0400, Dmitry V. Levin wrote:
> > > > По окончании сборки имя spm-пакета сравнивается с заявленным, и в случае
> > > > несовпадения результат сборки отвергается.
> > > 
> > > Тогда я не вижу, почему maintainer хочет публиковать свой приватный
> > > репозитарий под другим именем.  Допустим кто-то публикует питон по
> > > адресу perl.git.  Какой в этом смысл?  Названия публичного и приватного
> > > репозитариев отличается, find-package не работает.
> > 
> > У меня есть несколько репозиториев, из которых я собираю пакеты с разными
> > именами, напр. readline*, openssl* и т.п.
> > 
> > Т.е. причина простая: из одного репозитория собирается несколько разных
> > родственных пакетов.
> 
> То есть у тебя лежит всего один readline.git, а в публичном хранилище
> будет публиковаться несколько readline*.git репозитариев?  Хм, некузяво.

Ну, мне удобнее хранить несколько readline* в одном readline.git

> Хотелось бы достичь 1-1 соответствия между именами публичных и приватных
> репозитариев.

Так ли это важно?  А если как-нибудь публиковать адрес gear-репозитория,
из которого производилась сборка?

> А то точно кто-нибудь будет публиковать питон по адресу perl.git. :)

И я знаю этого кто-нибудь. ;)

[...]
> > Если что-то можно проверить ещё до сборки, то почему бы этого не сделать?
> > Поскольку проверка git-merge-base дешевле сборки, в этом есть смысл:
> > экономия ресурсов.
> 
> Отчасти так, хотя экономия ресурсов не обещает быть заметной, если
> только уважаемые товарищи maintainer'ы не устроят флешмоба "пошли на
> сборку запрос который не наследует от предыдущей сборки".

На этот случай можно предусмотреть экспоненциальное замедление:
одна ошибка наследования -- 1 условная минута задержки обработки запросов
на сборку от товарища, N ошибок наследования подряд -- 2^(N-1) условных
минут задержки, каждая успешная сборка сбрасывает счётчик ошибок
наследования.

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


-- 
ldv

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

Re: [devel] giter-factory: pkg_build_status

[Kirill Shutemov]

On 8/30/07, Dmitry V. Levin <ldv@altlinux.org> wrote:
> On Thu, Aug 30, 2007 at 09:50:13PM +0400, Alexey Tourbin wrote:
> > То есть у тебя лежит всего один readline.git, а в публичном хранилище
> > будет публиковаться несколько readline*.git репозитариев?  Хм, некузяво.
>
> Ну, мне удобнее хранить несколько readline* в одном readline.git
>
> > Хотелось бы достичь 1-1 соответствия между именами публичных и приватных
> > репозитариев.
>
> Так ли это важно?  А если как-нибудь публиковать адрес gear-репозитория,
> из которого производилась сборка?
Можно вешать тэг с URL'ом в публичном репозитории. Только не факт, что
репозиторий не удалят или не перепишут историю или ещё чего...

Re: [devel] giter-factory: pkg_build_status

[Dmitry V. Levin]

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

On Thu, Aug 30, 2007 at 03:06:41PM +0400, Alexey Tourbin wrote:
> Теперь детализирую эти идеи на псведокоде.  Знак "=" касается
> структур данных, знак "::" означает функцию, стрелка "->"
> означает тип (сигнатуру) функции.

Не смог понять этот псведокод.  Где можно ознакомиться с описанием?


-- 
ldv

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

Re: [devel] giter-factory: pkg_build_status

[Alexey Tourbin]

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

On Thu, Aug 30, 2007 at 08:01:48PM +0400, Dmitry V. Levin wrote:
> On Thu, Aug 30, 2007 at 03:06:41PM +0400, Alexey Tourbin wrote:
> > Теперь детализирую эти идеи на псведокоде.  Знак "=" касается
> > структур данных, знак "::" означает функцию, стрелка "->"
> > означает тип (сигнатуру) функции.
> 
> Не смог понять этот псведокод.  Где можно ознакомиться с описанием?

Шелл-код не позволяет определять сигнатуру функции, то есть данные
какого типа функция получает на входе и данные какого типа у неё
на выходе.  Поэтому сразу писать на шелле смысла нет, если мы
определяемся с информацией типа чево куда пойдёт.

Вообще-то лучше всего описывать преобразование абстрактных типов данных
позволяет язык типа Хаскелль.  Я его плохо знаю.  Кажется, два человека
в team хорошо знают Хаскелль, но это прямо сейчас вряд ли поможет.

Мой псевдокод, тем не мене, почти произволен.
Я лишь полагаюсь на то, что он вызовет правильные ассоциации.

Остается только перевести на русский.

gear-request =
	gear-repo
	commit-id
	packager = invoker

gear-request -- это структура данных, которая включает в себя
путь к gear-репозитарию, commit-id для сборки и packager, которым
считается тот, кто дал запрос на сборку.

build_arch :: gear-request -> build_arch_status
	can_build_srpm = gear hsh --build-args=-bs
	srpm_NSVR = rpm -qp srpm
	BuildRequires = rpm -qpR srpm
	buildroot_base = hsh --initroot, hsh-shell rpm -qa
	buildroot_BR = hsh-install BuildRequires, hsh-shell rpm -qa
	buildroot_BR = buildroot_BR \setminus buildroot_base
	hasher_exit_status = gear hsh
	build_arch_status =
		gear-request
		can_build_srpm
		srpm_NSVR
		BuildRequires
		buildroot_base
		buildroot_BR
		hasher_exit_status
		RPMS.hasher/*.rpm

Функция build_arch собирает gear-репозитарий для данной архитектуры.
На входе она берёт gear-request, а на выходе отдаёт структуру данных
build_arch_status, которая включает в себя gear-request,
can_build_srpm -- возможность превичной запаковки src.rpm пакета из
gear-репозитария, srpm_NSVR -- "%name %serial:%version-%release",
BuildRequires -- зависимости src.rpm пакета, buildroot_base --
содержимое сборочного чрута после --initroot, buildroot_BR --
дополнительные пакеты, которые поставились в чрут для сборки,
hasher_exit_status -- собрался пакет или нет, и RPMS.hasher/*.rpm --
собранные пакеты.

check_build_status :: build_arch_status+ -> pkg_build_status | reject
	all primary arches must build (hasher_exit_status = 0 for primary_arches)
	all srpm_NSVR must be the same (map this.srpm_NSVR build_arch_status+ |sort -u |wc -l => 1)
	require that $(basename gear-request.gear-repo .git) exactly matches srpm_NSVR.name
	if has public gear-request.gear-repo; then
		check commit ancestry $(public gear-repo) gear-request.commit-id
	fi
	if at least one RPMS.hasher/*.rpm is noarch; then
		# noarch packages must build essentially the same on all arches
		# otherwise we DO NOT KNOW how to move them to sisyphus
		RPMS.hasher/*.rpm set must be the same for all arches
		rpm -qpl set must be the same for each RPMS.hasher/*.rpm for all arches
		rpm -qp --requires set must be the same for each RPMS.hasher/*.rpm for all arches
		rpm -qp --provides set must be the same for each RPMS.hasher/*.rpm for all arches, etc.
	fi
	pkg_build_status =
		pkg = srpm_NSVR
		build_arch_status+


Фунция check_build_status дает простой ответ на сложный вопрос: собрался
пакет или нет.  На входе она берёт массив build_arch_status (результаты
сборки на всех архитектурах), а на выходе возвращает "maybe pkg_build_status"
(в терминах хаскелля), то есть если ответ "да", то она возвращает
структуру pkg_build_status, а если ответ "нет" то она возвращает reject
(аналог NULL + отлуп maintainer'у -- типа всё дело, закрыто).

В псевдокоде подразумевается reject, когда не выполняется какое-то
условие.  Условия эти такие:

	Пакет должен собраться на всех основных архитектурах.
	У всех полученных src.rpm пакетов должен совпадать NSVR.
	(новое требование) Название gear-репозитария и src.rpm пакета должны совпадать.
	Если в результатах сборки есть хотя бы один noarch пакет, то
		На всех архитектурах список RPMS.hasher/*.rpm должен совпадать
		На всех архитектурах для каждого собранного пакета вывод rpm -qpl должен совпадать.
		Далее вывод rpm -qp --requires, rpm -qp --provides и т.д.

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

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