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

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

[Alexey Tourbin]

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

On Tue, Nov 06, 2007 at 05:46:44PM +0300, Dmitry V. Levin wrote:
> Проблема в том, что действующую систему сборки хочется трогать как можно
> меньше, поскольку ещё есть надежда перейти на новую систему сборки
> в обозримом будущем.

Надеяться не вредно.  В свое время на консультации перед первым
экзаменом по высшей математике я задал преподавателю два вопроса:
1) какие оценки Вы обычно ставите; и 2) стоит ли надеяться на хорошую
оценку.  Ответы были соответственно 1) оценки бывают разные; и
2) надеяться можно всегда.  (Оценка на экзамене была удовлетворительной --
я не понимал, что такое последовательность Коши.  Через две недели я
пошел на пересдачу и мне поставили хорошую оценку.  Полтора года спустя
итоговая оценка была отличной.)

Можно не только надеяться, но и пытаться понять суть вещей.

Я предлагаю попытаться понять и обсуждать более фундаментальные вещи
(если есть что обсуждать), не опускаясь до техники реализации.  Но это
идёт рука об руку.  Когда уже становится достаточно понятно, что нечно
подлежит реализации, то это становится достаточно просто реализовать.

Некоторое время назад я писал про желаемую процедуру прохождения
пакетов.  Теперь надо посмотреть на это с другой стороны -- на какой
структуре данных эта процедура будет работать.

Нужно дать "более алгебраическое" описание желаемой действительности,
а именно, какие элементарные множества у нас имеются, и какие
элементарные операции к элементам этих множеств применимы.
Алгебраическая строгость, конечно, быстро пропадёт, но она по крайней
мере помогает понять "что к чему" на ранних этапах.

Я уже писал, что прохождение новых пакетов в сизиф подобно "коммитам"
в некоем "репозитарии" пакетов (метарепозитарии).  Наивная сериализация
склоняет к линейной истории коммитов, но практика говорит о том, что
любой "неудачный коммит" всего лишь открывает транзакцию, которая,
при условии устранения всех "неудачных моментов" может быть потом
"слита" (merge) в mainline (HEAD) репозитария.

То есть, выражаясь более эзотерически, существует некий "холизм",
когда "борьба" или "духовная брань" на земле отображется в это самое
дело на небе, а "поле битвы -- сердца людей" (Достоевский).  Это значит,
что история "настоящего пакета" должна находить отражение в истории
"метарепозитария" в целом. Прошу прощения за отклонение в изотерику.
Идея в целом достаточно важна, но мои вербальные возможности столь же
скудны.

Нет никакой нужды дальше поддерживать мнимое существование
"метарепозитария Сизифа".  Можно это понятие эксплицировать, и сказать,
что метарепозитария Сизифа -- это обычный git-репозитарий, в котором
хранится существенная информация о пакетах в Сизифе.  Это информация
является достаточной, а в основном и необходимой, для дальнейшего
продвижения "хеда" репозитария.

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

Рассмотрим пример.  Пришёл пакет perl-XML-LibXML, и он "собрался"
(собираемость пакета является уточняемым понятием).  Дальше предстоит
некое довольно долгое тестирование репозитария на предмет того, что
новый пакет ничего не ломает.  Это значит, что каждый входящий пакет
открывает входящую транзакцию, по номеру серийного задания.  Пусть номер
задания будет 333, и пакет perl-XML-LibXML собрался.  Создается бранч 333.

	* branch 333: perl-XML-LibXML built ok
	 `* HEAD -- current sisyphus

Имеется попытка перевода репозитария в новое целостное состояние --
с новым пакетом perl-XML-LibXML.  Происходят всевозможные тестирования,
в частности, пересборка пакета perl-XML-LibXSLT.

	* perl-XML-LibXSLT rebuilt ok (perl-XML-LibXSLT/ updated)
	* branch 333: perl-XML-LibXML built ok
	 `* HEAD -- current sisyphus

Когда всё тестирование прошло без обломов, тогда merge нового бранча
(или же "commit") происходит автоматически.

	 /* HEAD -- merge new perl-XML-LibXSLT into current sisyphus
	* | perl-XML-LibXSLT rebuilt ok (perl-XML-LibXSLT/ updated)
	* | branch 333: perl-XML-LibXML built ok
	 `* HEAD -- current sisyphus

На самом деле здесь будет "fast forward", то есть в простейшем случае,
если иметь в виду сериализацию заданий, не нарушается линейность истории.

В более неудачном случае merge не может быть простым "fast forward",
и здесь потребуется sophisticated стратегия мёржа.  Стратегии мёржа
метарепозитария я не буду обсуждать раньше времени, чтобы не усложнять
того что по сути просто.

Короче, есть такое дело -- МОЗГОВОЙ ШТУРМ.
Я предлагаю сделать метарепозитарий сизифа, в котором содержится
необходимя и достаточная информация для поддержки "новой системы сборки
пакетов".  На каждый src.rpm пакет имеется соответствующий подкаталог
метарепозитария.

Вопрос по части мозгового штурма у меня к вам простой -- ЧТО ДОЛЖНО
ЛЕЖАТЬ В ПОДКАТАЛОГАХ ЭТОГО РЕПОЗИТАРИЯ?  (У меня есть тетрадка в
которой исчеркано несколько страниц на эту тему... но я прошу высказать
то что сходу приходит вам в голову.)

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

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

[Alexey Tourbin]

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

On Wed, Nov 07, 2007 at 04:31:53AM +0300, Evgeny Sinelnikov wrote:
> > Вопрос по части мозгового штурма у меня к вам простой -- ЧТО ДОЛЖНО
> > ЛЕЖАТЬ В ПОДКАТАЛОГАХ ЭТОГО РЕПОЗИТАРИЯ?  (У меня есть тетрадка в
> > которой исчеркано несколько страниц на эту тему... но я прошу высказать
> > то что сходу приходит вам в голову.)
> 
> Если отталкиваться от текущей схемы работы с gear, то уже возникает целое
> множествое вариантов. Все они, в общем, сводятся к тому, что в подкаталоге
> src.rpm пакета находятся набор файлов сборки, spec файл и правила
> формирования содержимого этого src.rpm пакета из набора файлов сборки.

Вы не поняли, это метарепозитарий.  Там не будет никаких исходников,
там у каждого пакета будет однообразная жёсткая структура данных типа
"зависимости пакета" и т.д.  Соответственно если мы пересобрали один
пакет, потом при тестировании транзитивно пересобрались все зависимые
пакеты.  Будет легко узнать, изменились зависимости у зависимых пакетов
или нет.  Например, на таком репозитарии будет легко отслеживать смену
сонейма (автоматически или полуавтоматически).

Вы меня расстраиваете непониманием, и кажется, что я смолол какую-то
ахинею, при том что у меня вроде была какая-то простая и красивая мысля.

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

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

[Хихин Руслан]

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

Здравствуйте Alexey Tourbin
  В сообщении от 7 ноября 2007 Alexey Tourbin написал(a):
 > Вы не поняли, это метарепозитарий.  Там не будет никаких исходников,
 >
 > там у каждого пакета будет однообразная жёсткая структура данных
 > типа
 > "зависимости пакета" и т.д.  Соответственно если мы пересобрали один
 > пакет, потом при тестировании транзитивно пересобрались все
 > зависимые
 >
 > пакеты.  Будет легко узнать, изменились зависимости у зависимых
 > пакетов
 > или нет.  Например, на таком репозитарии будет легко отслеживать
 > смену
 > сонейма (автоматически или полуавтоматически).

Говоря о зависимостях :

Имеем зависимость:
I - между бинарными пакетами 
важно при 
 1 посроении дистрибутива в spt 
 2 установки нового пакета в работающую систему
 3 включения в репозиторий нового или обновлённого пакета

II - между бинарными пакетами и сборкой пакета (buildreq)
только в этом случае срашны циклические зависимости.

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

Как я понимаю, вы пытаетесь свести всё к  зависимостям типа I ?
А механизм ваш сейчас работает на выяснении зависимостей типа III.
Отсюда некоторое непонимание. Важнее для Сизифа зависимости типа III. 
Возникают вопросы (чисто логически, не углубляясь в детали и конкретику)
- Как получить непротиворечивую транзакцию
- Какое время имеет смысл накапливать транзакцию
Требуются :
- Алгоритм включения поступившего пакета в имеющиеся транзакции
- Алгоритм создания транзакции
- Критерий готовности транзакции.
- Критерий устаревания транзакции.

-- 
С  уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Alexey Tourbin]

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

On Wed, Nov 07, 2007 at 08:50:59AM +0300, Хихин Руслан wrote:
> Имеем зависимость:
> I - между бинарными пакетами 
> важно при 
>  1 посроении дистрибутива в spt 
>  2 установки нового пакета в работающую систему
>  3 включения в репозиторий нового или обновлённого пакета
> 
> II - между бинарными пакетами и сборкой пакета (buildreq)
> только в этом случае срашны циклические зависимости.
> 
> III - между исходниками и пакетами (src.rpm в любом виде), которые 
> поступили на сборку и тем репозиторием, который уже есть.
>  Тут как разделящуюся боеголовка - из одного пакета может получиться 
> несколько, и одного из них достаточно, чтобы нарушить целостность 
> репозитория.
> 
> Как я понимаю, вы пытаетесь свести всё к  зависимостям типа I ?
> А механизм ваш сейчас работает на выяснении зависимостей типа III.
> Отсюда некоторое непонимание. Важнее для Сизифа зависимости типа III. 

Я веду мозговой штурм.  Мы хотим сделать метарепозитарий, который
содержит "необходимую и достаточную" информацию о пакетах.  Он
"отражает" прохождение пакетов таким образом, что, грубо говоря,
можно "автоматически или полуавтоматически" судить, ухудшает
каждый очередной пакет характеристики репозитария или нет.
Если пакет ухудшает характеристики репозитария слишком подозрительно,
то форкается бранч до разрешения всех противоречий.

Иными словами, более эзотерически, мы не хотим автоматически увеличивать
энтропию.  В репозитарии автоматически разрешаются переходы только из
одного достаточно целостного состояния в другое НЕ МЕНЕЕ ЦЕЛОСТНОЕ
состояние.  Но в противном случае система не должна быть слишком
навязчивой -- в ней будут какие-то ручки, которые будут крутить люди.

Мы хотим сделать структуру данных репозитария СИЗИФУС, которая позволяет
вычислять некую весовую функцию ЦЕЛОСТНОСТЬ репозитария при прохождении
каждого очередного пакета.  Если ЦЕЛОСТНОСТЬ падает, то форкается бранч.
Если ЦЕЛОСТНОСТЬ не ухудшатеся, пакет проходит автоматически (мёрж/commit
типа fast forward).

(Весовую функцию нужно понимать эзотерически.  Она "помогает понять",
но сама не нужна и скорее всего будет вредна, т.к. "не учитывает связи"
и т.п.)

Что должно храниться в этом репоизатрии?
Мы хотим отказаться от src.rpm пакетов.
В каждом src.rpm пакете есть список BuildRequires.
На "алгебраическом" уровне нельзя предполагать, что это список был
сформирован при помощи buildreq или как-то ещё.

Значит, в метарепозитарии для каждого "исходного" пакета нужно хранить:
1) список BuildRequires as is;
2) транзитивное замыкание BuildRequires в той среде, в которой этот
пакет был первоначально собран, т.е. список %name-%version-%release
сборочного чрута.
3) список подпакетов, которые собрались;
4+) настоящие зависимости собранных подпакетов.

Тогда становится возможным обнаружение смены сонейма.  На этой структуре
данных критерий смены сонейма можно сформулировать примерно так.
Напомню, что есть две стадии: "пакет собрался" и "пакет проходит".
На стадии "пакет собрался" критерий это изменился Provides определенного
вида (lib*.so*).  На стадии "пакет подходит" будет пересборка всех
транзитивно зависимых пакетов.  По окончании этой стадии критерий будет
СИНХРОННАЯ смена Requires того же вида зависимостей, которые были учтены
на первой стадии.

> Возникают вопросы (чисто логически, не углубляясь в детали и конкретику)
> - Как получить непротиворечивую транзакцию
> - Какое время имеет смысл накапливать транзакцию
> Требуются :
> - Алгоритм включения поступившего пакета в имеющиеся транзакции
> - Алгоритм создания транзакции
> - Критерий готовности транзакции.
> - Критерий устаревания транзакции.

Вы уже обсуждаете ПОЛИТИКУ реализации.  Вы хотите немало.  Чтобы это
сделать, нужно пока обсуждать БАЗОВЫЕ МЕХАНИЗМЫ, на основе которых эта
реализация СМОЖЕТ работать.  В частности, я выдвинул идею
метарепозитария сизифа.  Мозговой штурм сейчас касается того, что
типа как бы всё это можно было устроить на уровне организации данных,
чтобы желаемое стало более возможным.

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

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

[Alexey I. Froloff]

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

* Alexey Tourbin <at@> [071107 00:36]:
> Вопрос по части мозгового штурма у меня к вам простой -- ЧТО
> ДОЛЖНО ЛЕЖАТЬ В ПОДКАТАЛОГАХ ЭТОГО РЕПОЗИТАРИЯ?
Куски pkgindex и srcindex от этого пакета.

Разбивка на бинарные пакеты пакеты.
Зависимости бинарных пакетов.
Сборочные зависимости (содержимое сборочного чрута в момент
сборки?).

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

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

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

[Alexey Gladkov]

Alexey I. Froloff wrote:
> Куски pkgindex и srcindex от этого пакета.
> 
> Разбивка на бинарные пакеты пакеты.
> Зависимости бинарных пакетов.
> Сборочные зависимости (содержимое сборочного чрута в момент
> сборки?).

+1

-- 
Rgrds, legion

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

[Alexey Gladkov]

Alexey Tourbin wrote:
> Короче, идея в следущем.  Есть git-репозитарий сизифа.  В нём существуют
> подкаталоги по имени каждого src.rpm пакета.  Прохождение любого
> пакета автоматически "влияет" на всё остальные (зависимые) пакеты по
> крайней мере в смысле возможности пересборки.

Идея хорошая и заманчивая.

-- 
Rgrds, legion

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

[Alexey Gladkov]

Alexey Tourbin wrote:
> Вопрос по части мозгового штурма у меня к вам простой -- ЧТО ДОЛЖНО
> ЛЕЖАТЬ В ПОДКАТАЛОГАХ ЭТОГО РЕПОЗИТАРИЯ?  (У меня есть тетрадка в
> которой исчеркано несколько страниц на эту тему... но я прошу высказать
> то что сходу приходит вам в голову.)

Как вариант, можно держать rpmbox с этим пакетом или пакетами.

-- 
Rgrds, legion

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

[Alexey Gladkov]

Alexey Gladkov wrote:
> Как вариант, можно держать rpmbox с этим пакетом или пакетами.
> 

Даже не столько rpmbox сколько саму базу. rpmheader подразумевает
расширение своих полей (этим и пользуется apt). Так что в rpm базу
можно поместить всё необходимое для pkglist, srclist, плюс там будет
вся метаинформация пакетов, плюс зависимости и т.д.

-- 
Rgrds, legion

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

[Kirill A. Shutemov]

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

On [Wed, 07.11.2007 10:01], Alexey Tourbin wrote:
> Что должно храниться в этом репоизатрии?
> Мы хотим отказаться от src.rpm пакетов.
> В каждом src.rpm пакете есть список BuildRequires.
> На "алгебраическом" уровне нельзя предполагать, что это список был
> сформирован при помощи buildreq или как-то ещё.
> 
> Значит, в метарепозитарии для каждого "исходного" пакета нужно хранить:
> 1) список BuildRequires as is;
> 2) транзитивное замыкание BuildRequires в той среде, в которой этот
> пакет был первоначально собран, т.е. список %name-%version-%release
> сборочного чрута.
> 3) список подпакетов, которые собрались;
> 4+) настоящие зависимости собранных подпакетов.

К списку явно напрашиваются Provides.

Пункты 1, 3, 4 можно представить ввиде хидеров rpm-пакетов.

-- 
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] Метарепозиторий Сизифа

[Dmitry V. Levin]

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

Hi,

On Wed, Nov 07, 2007 at 12:35:30AM +0300, Alexey Tourbin wrote:
[...]
> Короче, идея в следущем.  Есть git-репозитарий сизифа.  В нём существуют
> подкаталоги по имени каждого src.rpm пакета.  Прохождение любого
> пакета автоматически "влияет" на всё остальные (зависимые) пакеты по
> крайней мере в смысле возможности пересборки.
[...]
> Я предлагаю сделать метарепозитарий сизифа, в котором содержится
> необходимя и достаточная информация для поддержки "новой системы сборки
> пакетов".  На каждый src.rpm пакет имеется соответствующий подкаталог
> метарепозитария.
> 
> Вопрос по части мозгового штурма у меня к вам простой -- ЧТО ДОЛЖНО
> ЛЕЖАТЬ В ПОДКАТАЛОГАХ ЭТОГО РЕПОЗИТАРИЯ?

Мы обдумали этот вопрос в узком кругу (avm и ldv).
Резюме для тех, кто не будет читать дальше:
- для сборки транзакции нужен снапшот всего Сизифа;
- сделать снапшот всего Сизифа стоит недорого;
- не стоит для реализации fast forward и rebase использовать git.

Теперь более подробно.

Публикуемый Сизиф развивается линейно и последовательно, т.е. множество
опубликованных Сизифов можно пронумеровать натуральными числами.
Определённые таким образом номера можно использовать в качестве
уникальных идентификаторов публикаций Сизифа.

Сборка транзакции (A) происходит следующим образом:
- создаётся репозиторий - снапшот текущего опубликованного Сизифа (Ra);
  использование ссылок делает эту операцию дешевой;
- на этом снапшоте выполняется сборка --with-stuff исходных пакетов
  транзакции; если хотя бы один не собрался, то транзакция отменяется
  (в первой реализации сборочной системы не вижу смысла оптимизировать
  эту часть);
- на основе Ra и свежесобранных пакетов формируется новый Сизиф (Ra');
- сравниваются анметы Ra и Ra';
  в случае появления новых анметов транзакция откладывается;
- вычисляется множество (Sa') исходных пакетов в Ra', для сборки которых
  требуются свежесобранные пакеты транзакции A (точнее говоря, в сборочной
  среде которых присутствует хотя бы один из свежесобранных пакетов);
- на Ra' выполняется тестовая сборка всех пакетов из Sa';
- если хотя бы один пакет перестал собираться (по сравнению со статистикой
  сборки на Ra), то транзакция откладывается;
- (*) предпринимается попытка применить успешно собранную транзакцию к Сизифу;
  если опубликованный на этот момент Сизиф совпадает с тем Сизифом, на
  основе которого был создан снапшот Ra, то происходит fast forward:
  Ra' становится Сизифом, которому присваивается очередной номер;
  в противном случае предпринимается попытка выполнить rebase:
- создаётся репозиторий - снапшот текущего опубликованного Сизифа (Rb);
- вычисляется множество (Nab) пакетов, которое появилось/обновилось в Rb по
  сравнению с Ra; здесь предполагается, что один и тот же исходный пакет
  не может попасть в более чем одну незавершённую транзакцию;
- если в транзакции есть пакеты более старой сборки, чем одноимённые пакеты
  в Nab, то транзакция отменяется (в первой реализации сборочной системы
  не вижу смысла оптимизировать эту часть);
- на Rb заново собираются --with-stuff те пакеты из A, в сборочной среде
  которых присутствуют пакеты из Nab;
- на основе Rb и собранных пакетов A формируется новый Сизиф (Rb');
- сравниваются анметы Rb и Rb';
  в случае появления новых анметов транзакция откладывается;
- вычисляется множество (Sb') исходных пакетов в Rb', для сборки
  которых требуется хотя бы один из свежесобранных пакетов;
- на Rb' выполняется тестовая сборка всех пакетов из Sb';
  если хотя бы один пакет перестал собираться (по сравнению со статистикой
  сборки на Rb), то транзакция откладывается;
- предпринимается попытка применить успешно собранную транзакцию к Сизифу
  по вышеописанному алгоритму, см. (*).

Из этого описания можно сделать выводы о том, что нужно для обработки
транзакции:
- бинарный репозиторий Сизиф для сборки пакетов;
- быстрое формирование нового бинарного репозитория Сизифа на основе
  предыдущего и новых пакетов (есть ли у нас необходимые средства?);
- корректное вычисление анметов (действующий алгоритм apt-cache unmet,
  по всей видимости, игнорирует конфликты);
- быстрое вычисление подмножества исходных пакетов Сизифа, для сборки
  которых требуется пакеты из указанного подмножества бинарных пакетов
  Сизифа (у нас сейчас нет такого алгоритма);
- статистика сборки исходных пакетов Сизифа должна быть частью Сизифа.

Формулировка "транзакция откладывается" означает, что дальнейшая обработка
транзакции невозможна без вмешательства извне.  На практике это может
означать отмену транзакции, дополнение транзакции новыми исходными
пакетами (фактически формирование новой транзакции на основе отложенной),
или действия уполномоченных лиц по преодолению причин, из-за которых
транзакция была отложена.


-- 
ldv

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

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

[Sergey Vlasov]

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

On Thu, Nov 08, 2007 at 08:42:25PM +0300, Dmitry V. Levin wrote:
> Публикуемый Сизиф развивается линейно и последовательно, т.е. множество
> опубликованных Сизифов можно пронумеровать натуральными числами.
> Определённые таким образом номера можно использовать в качестве
> уникальных идентификаторов публикаций Сизифа.
> 
> Сборка транзакции (A) происходит следующим образом:
> - создаётся репозиторий - снапшот текущего опубликованного Сизифа (Ra);
>   использование ссылок делает эту операцию дешевой;
> - на этом снапшоте выполняется сборка --with-stuff исходных пакетов
>   транзакции; если хотя бы один не собрался, то транзакция отменяется
>   (в первой реализации сборочной системы не вижу смысла оптимизировать
>   эту часть);
> - на основе Ra и свежесобранных пакетов формируется новый Сизиф (Ra');

Видимо, на этом этапе нужно убирать из Ra' пакеты, указанные в
Obsoletes у свежесобранных.  При этом может возникнуть ситуация, когда
часть бинарных пакетов, происходящих из одного исходного, указана в
Obsoletes, а часть - нет; что делать в этом случае?

> - сравниваются анметы Ra и Ra';
>   в случае появления новых анметов транзакция откладывается;
> - вычисляется множество (Sa') исходных пакетов в Ra', для сборки которых
>   требуются свежесобранные пакеты транзакции A (точнее говоря, в сборочной
>   среде которых присутствует хотя бы один из свежесобранных пакетов);

... либо хотя бы один из тех пакетов, которые были убраны из-за
Obsoletes.

> - на Ra' выполняется тестовая сборка всех пакетов из Sa';
> - если хотя бы один пакет перестал собираться (по сравнению со статистикой
>   сборки на Ra), то транзакция откладывается;
> - (*) предпринимается попытка применить успешно собранную транзакцию к Сизифу;
>   если опубликованный на этот момент Сизиф совпадает с тем Сизифом, на
>   основе которого был создан снапшот Ra, то происходит fast forward:
>   Ra' становится Сизифом, которому присваивается очередной номер;
>   в противном случае предпринимается попытка выполнить rebase:
> - создаётся репозиторий - снапшот текущего опубликованного Сизифа (Rb);
> - вычисляется множество (Nab) пакетов, которое появилось/обновилось в Rb по
>   сравнению с Ra; здесь предполагается, что один и тот же исходный пакет
>   не может попасть в более чем одну незавершённую транзакцию;
> - если в транзакции есть пакеты более старой сборки, чем одноимённые пакеты
>   в Nab, то транзакция отменяется (в первой реализации сборочной системы
>   не вижу смысла оптимизировать эту часть);
> - на Rb заново собираются --with-stuff те пакеты из A, в сборочной среде
>   которых присутствуют пакеты из Nab;

Здесь опять-таки нужно проверять ещё и исчезнувшие пакеты.

> - на основе Rb и собранных пакетов A формируется новый Сизиф (Rb');
> - сравниваются анметы Rb и Rb';
>   в случае появления новых анметов транзакция откладывается;
> - вычисляется множество (Sb') исходных пакетов в Rb', для сборки
>   которых требуется хотя бы один из свежесобранных пакетов;
> - на Rb' выполняется тестовая сборка всех пакетов из Sb';
>   если хотя бы один пакет перестал собираться (по сравнению со статистикой
>   сборки на Rb), то транзакция откладывается;
> - предпринимается попытка применить успешно собранную транзакцию к Сизифу
>   по вышеописанному алгоритму, см. (*).

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

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

[Alexey Tourbin]

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

On Thu, Nov 08, 2007 at 08:42:25PM +0300, Dmitry V. Levin wrote:
> Сборка транзакции (A) происходит следующим образом:
> - создаётся репозиторий - снапшот текущего опубликованного Сизифа (Ra);
>   использование ссылок делает эту операцию дешевой;
> - на этом снапшоте выполняется сборка --with-stuff исходных пакетов
>   транзакции; если хотя бы один не собрался, то транзакция отменяется
>   (в первой реализации сборочной системы не вижу смысла оптимизировать
>   эту часть);

Здесь есть тонкость: сборка --with-stuff второго и последующего пакетов
транзакции идёт со СТАРЫМИ contents_index_bin и contents_index_all.
То есть практика сборки --with-stuff потенциально может давать
неправильныме зависимости -- сразу же после фиксации транзакции
второый и последующие пакеты при тестовой пересборке могут получить
отличающиеся зависимости.  Так что здесь есть несколько подходов:
0) забить; 0a) пока забить; 1) делать в хешере локальный
contents_index_bin/all; 2) формировать временный сизиф после каждого
пакета транзакции и вести сборку уже на нём.  Это всё равно не до конца
решает вопрос, если зависимостями между пакетами в транзакции
топологически не упорядочены (то есть напр. при сборке первого пакета в
транзакции используется старая сборка одного из последующих пакетов).

> - на основе Ra и свежесобранных пакетов формируется новый Сизиф (Ra');
> - сравниваются анметы Ra и Ra';
>   в случае появления новых анметов транзакция откладывается;
> - вычисляется множество (Sa') исходных пакетов в Ra', для сборки которых
>   требуются свежесобранные пакеты транзакции A (точнее говоря, в сборочной
>   среде которых присутствует хотя бы один из свежесобранных пакетов);
> - на Ra' выполняется тестовая сборка всех пакетов из Sa';
> - если хотя бы один пакет перестал собираться (по сравнению со статистикой
>   сборки на Ra), то транзакция откладывается;
> - (*) предпринимается попытка применить успешно собранную транзакцию к Сизифу;
>   если опубликованный на этот момент Сизиф совпадает с тем Сизифом, на
>   основе которого был создан снапшот Ra, то происходит fast forward:
>   Ra' становится Сизифом, которому присваивается очередной номер;

До сих пор всё правильно.
Дальше самое трудное.

>   в противном случае предпринимается попытка выполнить rebase:
> - создаётся репозиторий - снапшот текущего опубликованного Сизифа (Rb);
> - вычисляется множество (Nab) пакетов, которое появилось/обновилось в Rb по
>   сравнению с Ra; здесь предполагается, что один и тот же исходный пакет
>   не может попасть в более чем одну незавершённую транзакцию;
> - если в транзакции есть пакеты более старой сборки, чем одноимённые пакеты
>   в Nab, то транзакция отменяется (в первой реализации сборочной системы
>   не вижу смысла оптимизировать эту часть);

Это нужно описать более точно ("алгебраически").
Имеется такая "структура коммитов" в метарепозитарии:

	     * Rb (HEAD)
	     |
	     * ...
branch Ra' * |
            `* Ra

Я на самом деле всегда об этом думал в терминах специальной "стратегии
мёржа" метарепозитария, и эта идея казалась мне полдотвороной.  Теперь
предлагается вместо мёржа делать ребейс.  Вообще-то ребейс хуже мёржа,
но в данном случае речь идёт примерно об одной и той же алгебраической
операции.  Мы хотим "насадить" изменение Ra->Ra' "сверху" на Rb.

То есть имеются изменения Nab=Ra->Rb' и Naa'=Ra->Ra'.
Можно ли их совместить "без конфликтов"?

(Важное замечание.  По сути речь идёт КРИТЕРИИ ВОЗМОЖНОСТИ мёржа/ребейса.
Этот критерий говорит о том, что эта операция ЛИБО ВОЗМОЖНА, ЛИБО
НЕВОЗМОЖНА.  Это замечание можно переформулировать так: нельзя
ребейсить что угодно на что угодно.)

Изменение Ra->Ra' в общем виде состоит в следующем следующем:
 	удалился src.rpm пакет	liba1	NSVR1
            вследствие чего
		удалился (arch|noarch).rpm пакет liba1-x	NSVR1
		удалился (arch|noarch).rpm пакет liba1-у	NSVR1
		...
	добавился src.rpm пакет liba2	NSVR2
	    вследствие чего
		добавился (arch|noarch).rpm пакет liba2-x	NSVR2
		добавился (arch|noarch).rpm пакет liba2-x	NSVR2
		...
	...

Замещение специальным образом рассматривать не надо -- оно сводится
к удалению+добавлению.

Простейший критерий мёржа/ребейса состоит в том, что должна сохраниться
возможность 1) удаления старых пакетов, с точностью до всех версий; и
2) добавления всех новых пакетов, без точности по версии.

А именно, попытка ребейса на Rb ПОСЛЕДОВАТЕЛЬНО проверяет возможность
применения к Rb операций:
	rm src.rpm liba1 NSVR1
		rm (arch|noarch).rpm liba1-x NSVR1
		rm (arch|noarch).rpm liba1-y NSVR1
	(если попытка удаления прошла хорошо, то
	 считается, что всё реально удалилось)
	add src.rpm liba2
	  (если liba2.src.rpm какой-либо версии уже есть, то облом)
		add (arch|noarch).rpm liba2-x
		  (если либо liba2-x.arch.rpm либо liba2-y.noarch.rpm уже
		   есть, то облом)
		add (arch|noarch).rpm liba2-y

Другими словами, это как бы "сильная" проверка на возможность
"перекладывания" собранных пакетов.  Она защищает от ситуации типа
перерспила пакетов или перетасовки собранных пакетов между исходными.

Но можно смотреть немного по-другому.  Здесь нужен ещё один слой защиты
от "частичного удаления" src.rpm пакетов.  То есть должна быть
алгебраическая операция "удалить src.rpm" пакет.  src.rpm пакет может
быть удалён только полностью, то есть в виде всех своих подпакетов.
А новый src.rpm может быть добавлен тоже только полностью, в виде всех
своих подпакетов.

Тогда критерий сводится к тому, что нужно иметь возможность 1) полностью
удалить тот же самый src.rpm пакет; 2) после удаления -- полностью
добавить новый src.rpm, то есть его быть не должно (любой версии),
ни каких-либо конфликтов по подпакетам (любых версий).

> - на Rb заново собираются --with-stuff те пакеты из A, в сборочной среде
>   которых присутствуют пакеты из Nab;
> - на основе Rb и собранных пакетов A формируется новый Сизиф (Rb');
> - сравниваются анметы Rb и Rb';
>   в случае появления новых анметов транзакция откладывается;
> - вычисляется множество (Sb') исходных пакетов в Rb', для сборки
>   которых требуется хотя бы один из свежесобранных пакетов;
> - на Rb' выполняется тестовая сборка всех пакетов из Sb';
>   если хотя бы один пакет перестал собираться (по сравнению со статистикой
>   сборки на Rb), то транзакция откладывается;
> - предпринимается попытка применить успешно собранную транзакцию к Сизифу
>   по вышеописанному алгоритму, см. (*).

Это рекурсивно что ли получается?
Мне надо ещё подумать.  Точнее, порисовать.

> Из этого описания можно сделать выводы о том, что нужно для обработки
> транзакции:
> - бинарный репозиторий Сизиф для сборки пакетов;
> - быстрое формирование нового бинарного репозитория Сизифа на основе
>   предыдущего и новых пакетов (есть ли у нас необходимые средства?);

Насколько быстрое?  Думаю что достаточно быстрое имеется.

> - корректное вычисление анметов (действующий алгоритм apt-cache unmet,
>   по всей видимости, игнорирует конфликты);

По крайней мере, если новый репозитарий правильно сформирован, то
'apt-cache unmet' помогает обнаруживать бездумную/unintented смену
сонейма.

> - быстрое вычисление подмножества исходных пакетов Сизифа, для сборки
>   которых требуется пакеты из указанного подмножества бинарных пакетов
>   Сизифа (у нас сейчас нет такого алгоритма);

30 минут на машине класса mash (см. мой query-rebuild.git).
Но это может быть намного быстрее на каком-нибудь Core2Duo,
и, следовательно, более приемлемо.

> - статистика сборки исходных пакетов Сизифа должна быть частью Сизифа.

Да.  Частью метарепозитария.  То есть нужно знать когда и в каком виде
пакет последний раз собрался и кое-что ещё.

> Формулировка "транзакция откладывается" означает, что дальнейшая обработка
> транзакции невозможна без вмешательства извне.  На практике это может
> означать отмену транзакции, дополнение транзакции новыми исходными
> пакетами (фактически формирование новой транзакции на основе отложенной),
> или действия уполномоченных лиц по преодолению причин, из-за которых
> транзакция была отложена.

Чем мёрж хуже ребейса.  При мёрже в метарепозитарии явно остаётся
информация, что нечто сломалось и потом починилось.  Это ИНТЕРЕСНО.
При ребейсе эта информация исчезает, и кажется, что как-будто всё
само шло хорошо и гладко.

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

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

[Kirill A. Shutemov]

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

On [Thu, 08.11.2007 22:03], Alexey Tourbin wrote:
> > Формулировка "транзакция откладывается" означает, что дальнейшая обработка
> > транзакции невозможна без вмешательства извне.  На практике это может
> > означать отмену транзакции, дополнение транзакции новыми исходными
> > пакетами (фактически формирование новой транзакции на основе отложенной),
> > или действия уполномоченных лиц по преодолению причин, из-за которых
> > транзакция была отложена.
> 
> Чем мёрж хуже ребейса.  При мёрже в метарепозитарии явно остаётся
> информация, что нечто сломалось и потом починилось.  Это ИНТЕРЕСНО.
> При ребейсе эта информация исчезает, и кажется, что как-будто всё
> само шло хорошо и гладко.

Можно сохранять Ra' и вешать тэги с нужной информацией в место куда
делался rebase.

-- 
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 --]

[devel] bootstrap транзакции

[Alexey Tourbin]

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

On Thu, Nov 08, 2007 at 10:03:28PM +0300, Alexey Tourbin wrote:
> On Thu, Nov 08, 2007 at 08:42:25PM +0300, Dmitry V. Levin wrote:
> > Сборка транзакции (A) происходит следующим образом:
> > - создаётся репозиторий - снапшот текущего опубликованного Сизифа (Ra);
> >   использование ссылок делает эту операцию дешевой;
> > - на этом снапшоте выполняется сборка --with-stuff исходных пакетов
> >   транзакции; если хотя бы один не собрался, то транзакция отменяется
> >   (в первой реализации сборочной системы не вижу смысла оптимизировать
> >   эту часть);
> 
> Здесь есть тонкость: сборка --with-stuff второго и последующего пакетов
> транзакции идёт со СТАРЫМИ contents_index_bin и contents_index_all.
> То есть практика сборки --with-stuff потенциально может давать
> неправильныме зависимости -- сразу же после фиксации транзакции
> второый и последующие пакеты при тестовой пересборке могут получить
> отличающиеся зависимости.  Так что здесь есть несколько подходов:
> 0) забить; 0a) пока забить; 1) делать в хешере локальный
> contents_index_bin/all; 2) формировать временный сизиф после каждого
> пакета транзакции и вести сборку уже на нём.  Это всё равно не до конца
> решает вопрос, если зависимостями между пакетами в транзакции
> топологически не упорядочены (то есть напр. при сборке первого пакета в
> транзакции используется старая сборка одного из последующих пакетов).

То есть транзакции является таковой лишь внешне.  Внутри же никакой
"атомарности" нет, и как бы существует проблема "bootstrap'а"
транзакии.  Если транзакция не является "слишком паталогической"
(не содержит "атаки"), то bootstrap транзакции можно решить двойной
пересборкой.  1) Сначала всё собрать в том порядке в каком есть;
2) упорядочить собранные пакеты топологически; 3) переупорядочить
соответствующим образом src.rpm пакеты; 4) собрать src.rpm пакеты
в новом порядке ещё раз.

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

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

[Alexey Tourbin]

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

On Thu, Nov 08, 2007 at 09:20:49PM +0200, Kirill A. Shutemov wrote:
> On [Thu, 08.11.2007 22:03], Alexey Tourbin wrote:
> > > Формулировка "транзакция откладывается" означает, что дальнейшая обработка
> > > транзакции невозможна без вмешательства извне.  На практике это может
> > > означать отмену транзакции, дополнение транзакции новыми исходными
> > > пакетами (фактически формирование новой транзакции на основе отложенной),
> > > или действия уполномоченных лиц по преодолению причин, из-за которых
> > > транзакция была отложена.
> > 
> > Чем мёрж хуже ребейса.  При мёрже в метарепозитарии явно остаётся
> > информация, что нечто сломалось и потом починилось.  Это ИНТЕРЕСНО.
> > При ребейсе эта информация исчезает, и кажется, что как-будто всё
> > само шло хорошо и гладко.
> 
> Можно сохранять Ra' и вешать тэги с нужной информацией в место куда
> делался rebase.

Мне нужна такая структура коммитов

	 /* merged new perl-XML-LibXML with fixed perl-XML-LibXSLT into master
	* | new perl-XML-LibXSLT built ok
	* | cannot rebuild perl-XML-LibXSLT
	 `* new perl-XML-LibXML built ok

При ребейсе будет просто одна транзакия: два пакета
perl-XML-LibXML и perl-XML-LibXSLT.  То что старый perl-XML-LibXSLT
при этом сломался эта информация будет потеряна.

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

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

[Dmitry V. Levin]

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

On Thu, Nov 08, 2007 at 09:38:16PM +0300, Sergey Vlasov wrote:
> On Thu, Nov 08, 2007 at 08:42:25PM +0300, Dmitry V. Levin wrote:
> > Публикуемый Сизиф развивается линейно и последовательно, т.е. множество
> > опубликованных Сизифов можно пронумеровать натуральными числами.
> > Определённые таким образом номера можно использовать в качестве
> > уникальных идентификаторов публикаций Сизифа.
> > 
> > Сборка транзакции (A) происходит следующим образом:
> > - создаётся репозиторий - снапшот текущего опубликованного Сизифа (Ra);
> >   использование ссылок делает эту операцию дешевой;
> > - на этом снапшоте выполняется сборка --with-stuff исходных пакетов
> >   транзакции; если хотя бы один не собрался, то транзакция отменяется
> >   (в первой реализации сборочной системы не вижу смысла оптимизировать
> >   эту часть);
> > - на основе Ra и свежесобранных пакетов формируется новый Сизиф (Ra');
> 
> Видимо, на этом этапе нужно убирать из Ra' пакеты, указанные в
> Obsoletes у свежесобранных.

Не факт, что их нужно убирать по этому признаку.

> При этом может возникнуть ситуация, когда
> часть бинарных пакетов, происходящих из одного исходного, указана в
> Obsoletes, а часть - нет; что делать в этом случае?

Пример: rpmquery --obsoletes libgcc4.1


-- 
ldv

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

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

[Dmitry V. Levin]

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

On Thu, Nov 08, 2007 at 10:03:28PM +0300, Alexey Tourbin wrote:
> On Thu, Nov 08, 2007 at 08:42:25PM +0300, Dmitry V. Levin wrote:
> > Сборка транзакции (A) происходит следующим образом:
> > - создаётся репозиторий - снапшот текущего опубликованного Сизифа (Ra);
> >   использование ссылок делает эту операцию дешевой;
> > - на этом снапшоте выполняется сборка --with-stuff исходных пакетов
> >   транзакции; если хотя бы один не собрался, то транзакция отменяется
> >   (в первой реализации сборочной системы не вижу смысла оптимизировать
> >   эту часть);
> 
> Здесь есть тонкость: сборка --with-stuff второго и последующего пакетов
> транзакции идёт со СТАРЫМИ contents_index_bin и contents_index_all.
> То есть практика сборки --with-stuff потенциально может давать
> неправильныме зависимости -- сразу же после фиксации транзакции
> второый и последующие пакеты при тестовой пересборке могут получить
> отличающиеся зависимости.  Так что здесь есть несколько подходов:
> 0) забить; 0a) пока забить; 1) делать в хешере локальный
> contents_index_bin/all; 2) формировать временный сизиф после каждого
> пакета транзакции и вести сборку уже на нём.  Это всё равно не до конца
> решает вопрос, если зависимостями между пакетами в транзакции
> топологически не упорядочены (то есть напр. при сборке первого пакета в
> транзакции используется старая сборка одного из последующих пакетов).

Транзакция состоит не просто из множества исходных пакетов, а из списка
исходных пакетов, т.е. это множество линейно упорядочено мантейнером.

Для решения вопроса зависимостей, порождаемых под влиянием contents_index,
можно действительно выбрать один из нескольких вариантов:
- формировать contents_index по окончании сборки каждого пакета в транзакции;
- формировать временный сизиф по окончании сборки каждого пакета в транзакции;
Кроме того, можно собирать пакеты транзакции в два прохода (второй после
проверки на анметы), но это не альтернатива вышеперечисленному.

[...]
> Имеется такая "структура коммитов" в метарепозитарии:
> 
> 	     * Rb (HEAD)
> 	     |
> 	     * ...
> branch Ra' * |
>             `* Ra
> 
> Я на самом деле всегда об этом думал в терминах специальной "стратегии
> мёржа" метарепозитария, и эта идея казалась мне полдотвороной.  Теперь
> предлагается вместо мёржа делать ребейс.  Вообще-то ребейс хуже мёржа,
> но в данном случае речь идёт примерно об одной и той же алгебраической
> операции.  Мы хотим "насадить" изменение Ra->Ra' "сверху" на Rb.

Честно говоря, я пока не вижу способа реализовать merge, который не есть
по сути rebase.

> То есть имеются изменения Nab=Ra->Rb' и Naa'=Ra->Ra'.
> Можно ли их совместить "без конфликтов"?
> 
> (Важное замечание.  По сути речь идёт КРИТЕРИИ ВОЗМОЖНОСТИ мёржа/ребейса.
> Этот критерий говорит о том, что эта операция ЛИБО ВОЗМОЖНА, ЛИБО
> НЕВОЗМОЖНА.  Это замечание можно переформулировать так: нельзя
> ребейсить что угодно на что угодно.)

Чем отличается критерий возможности rebase от критерия возможности сборки
вообще?  По идее, изменение Ra->Ra' можно преобразовать (rebase) в Ra->Rb',
если транзакцию A можно собрать на репозитории Rb.

[...]
> Но можно смотреть немного по-другому.  Здесь нужен ещё один слой защиты
> от "частичного удаления" src.rpm пакетов.  То есть должна быть
> алгебраическая операция "удалить src.rpm" пакет.  src.rpm пакет может
> быть удалён только полностью, то есть в виде всех своих подпакетов.
> А новый src.rpm может быть добавлен тоже только полностью, в виде всех
> своих подпакетов.

Видимо, да.

[...]
> > - предпринимается попытка применить успешно собранную транзакцию к Сизифу
> >   по вышеописанному алгоритму, см. (*).
> 
> Это рекурсивно что ли получается?

Скорее итеративно.

> > Из этого описания можно сделать выводы о том, что нужно для обработки
> > транзакции:
> > - бинарный репозиторий Сизиф для сборки пакетов;
> > - быстрое формирование нового бинарного репозитория Сизифа на основе
> >   предыдущего и новых пакетов (есть ли у нас необходимые средства?);
> 
> Насколько быстрое?

Быстрее чем среднее время сборки пакета.

> Думаю что достаточно быстрое имеется.

В каком виде?

> > - корректное вычисление анметов (действующий алгоритм apt-cache unmet,
> >   по всей видимости, игнорирует конфликты);
> 
> По крайней мере, если новый репозитарий правильно сформирован, то
> 'apt-cache unmet' помогает обнаруживать бездумную/unintented смену
> сонейма.

Это отдельная проблема.  Просто она всплыла в процессе обдумывания, и я
отметил её.  В первом приближении можно пренебречь.

> > - быстрое вычисление подмножества исходных пакетов Сизифа, для сборки
> >   которых требуется пакеты из указанного подмножества бинарных пакетов
> >   Сизифа (у нас сейчас нет такого алгоритма);
> 
> 30 минут на машине класса mash (см. мой query-rebuild.git).
> Но это может быть намного быстрее на каком-нибудь Core2Duo,
> и, следовательно, более приемлемо.

В машинах класса mash измерять уже не интересно, но 30 минут -- это
довольно много.

> > - статистика сборки исходных пакетов Сизифа должна быть частью Сизифа.
> 
> Да.  Частью метарепозитария.  То есть нужно знать когда и в каком виде
> пакет последний раз собрался и кое-что ещё.

В моих рассуждениях было достаточно знать про каждый исходный пакет в
Сизифе Ra, собирался он или нет.  Зачем может быть нужно что-то ещё?

> > Формулировка "транзакция откладывается" означает, что дальнейшая обработка
> > транзакции невозможна без вмешательства извне.  На практике это может
> > означать отмену транзакции, дополнение транзакции новыми исходными
> > пакетами (фактически формирование новой транзакции на основе отложенной),
> > или действия уполномоченных лиц по преодолению причин, из-за которых
> > транзакция была отложена.
> 
> Чем мёрж хуже ребейса.

Процедура, согласно которой изменение A, первоначально сделанное для
репозитория Ra, "проигрывается" на репозитории Rb, называется rebase.
Если хочешь, называй это merge, я не против, но rebase, как мне кажется,
лучше отражает суть происходящего.

> При мёрже в метарепозитарии явно остаётся
> информация, что нечто сломалось и потом починилось.  Это ИНТЕРЕСНО.

Если во время rebase что-то сломалось, то это уже не совсем чистый rebase.

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

Наверное, можно сохранять промежуточные состояния жизни транзакции, если
это интересно.  Я пока не вижу, зачем это может понадобиться.


-- 
ldv

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

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

[Alexey Tourbin]

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

On Fri, Nov 09, 2007 at 12:20:02AM +0300, Dmitry V. Levin wrote:
> Транзакция состоит не просто из множества исходных пакетов, а из списка
> исходных пакетов, т.е. это множество линейно упорядочено мантейнером.

В каком порядке заливать транзакцию gcc4.x + glibc?
Есть небольшой риск, что сразу после фиксации транзакции либо gcc
не будет собираться с glibc, либо glibc не будет собираться с gcc.
Может быть это даже допустимо и в этом есть какой-то смысл.
Но, в общем, внутри "атомарной" транзакции есть свои тонкости,
она атомарна снаружи но не совсем атомарна внутри.

> Для решения вопроса зависимостей, порождаемых под влиянием contents_index,
> можно действительно выбрать один из нескольких вариантов:
> - формировать contents_index по окончании сборки каждого пакета в транзакции;
> - формировать временный сизиф по окончании сборки каждого пакета в транзакции;
> Кроме того, можно собирать пакеты транзакции в два прохода (второй после
> проверки на анметы), но это не альтернатива вышеперечисленному.

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

> Честно говоря, я пока не вижу способа реализовать merge, который не есть
> по сути rebase.

А что такое тогда "merge" (вообще), который нельзя рассматривать как
"подстёгивание" ещё одной цепочки изменений?  То есть чем
"подстёгивание" отличается от "проигрывания сверху"?  В гите
понятие мёржа как бы вообще немного дефектно, в точке мёржа
можно выдать произвольное дерево.  То есть в точке мёржа
происходит какой-то нематематический катаклизм -- после мёржа
уже нельзя однозначно восстановить коммиты parent-бранчей.
То есть при мёрже можно слить что угодно с чем угодно,
а при ребейсе такого не бывает.

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

> > То есть имеются изменения Nab=Ra->Rb' и Naa'=Ra->Ra'.
> > Можно ли их совместить "без конфликтов"?
> > 
> > (Важное замечание.  По сути речь идёт КРИТЕРИИ ВОЗМОЖНОСТИ мёржа/ребейса.
> > Этот критерий говорит о том, что эта операция ЛИБО ВОЗМОЖНА, ЛИБО
> > НЕВОЗМОЖНА.  Это замечание можно переформулировать так: нельзя
> > ребейсить что угодно на что угодно.)
> 
> Чем отличается критерий возможности rebase от критерия возможности сборки
> вообще?  По идее, изменение Ra->Ra' можно преобразовать (rebase) в Ra->Rb',
> если транзакцию A можно собрать на репозитории Rb.

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

> > > Из этого описания можно сделать выводы о том, что нужно для обработки
> > > транзакции:
> > > - бинарный репозиторий Сизиф для сборки пакетов;
> > > - быстрое формирование нового бинарного репозитория Сизифа на основе
> > >   предыдущего и новых пакетов (есть ли у нас необходимые средства?);
> > 
> > Насколько быстрое?
> Быстрее чем среднее время сборки пакета.
> > Думаю что достаточно быстрое имеется.
> В каком виде?

Это грамотное удаление дупов + genbasedir.
Несколько минут наверное.
Только gpg-подписи там не будет, или же в чём здесь загвоздка?

> > По крайней мере, если новый репозитарий правильно сформирован, то
> > 'apt-cache unmet' помогает обнаруживать бездумную/unintented смену
> > сонейма.
> 
> Это отдельная проблема.  Просто она всплыла в процессе обдумывания, и я
> отметил её.  В первом приближении можно пренебречь.

Не совсем понял.  Проблемами как раз пренебрегать нельзя.  Мы как бы как
раз хотим научиться решать (или хотя бы формулировать) достаточно
трудные прикладные проблемы.  Для этого нужно иметь достаточно богатую
структуру данных по предметной области.  Я называю её "метарепозитарий",
хотя эзотерика здесь пристёгнута не всерьез а скорее в шутку.

> > 30 минут на машине класса mash (см. мой query-rebuild.git).
> > Но это может быть намного быстрее на каком-нибудь Core2Duo,
> > и, следовательно, более приемлемо.
> В машинах класса mash измерять уже не интересно, но 30 минут -- это
> довольно много.

Да.  Это самое слабое место.  После того, как собрались пакеты
транзакции, нужно ждать какое-то время, пока не просчитается список
на тестовую пересборку.  Это время в среднем наверное превышает сборку
поступивших пакетов + последующую тестовую пересборку.

> > Да.  Частью метарепозитария.  То есть нужно знать когда и в каком виде
> > пакет последний раз собрался и кое-что ещё.
> 
> В моих рассуждениях было достаточно знать про каждый исходный пакет в
> Сизифе Ra, собирался он или нет.  Зачем может быть нужно что-то ещё?

Ну например ты писал, что имеешь привычку сравнивать логи сборки
пакетов.  Вот в метарепозитарии например можно хранить логи сборки
пакетов.  Тогда систематическое сравнение логов сборки станет простой
процедурой.

Хотя дело здесь не в логах, лог -- это плохой пример.
Нужно хранить как минимум зависимости пакетов.  Зависимости пакета
после очередной его тестовой пересборки могут отличаться -- сильно
или не очень.  Это нужно обязательно знать иметь как бы "интерфейс"
доступа к этой информации.  Сейчас единственный дурацкий дубовый
интерфейс к этому делу называется qa-robot/cosubilode.  Им могут
воспользоваться ограниченное число людей.  По сути никто не знает,
как меняются зависимости у пакетов после очередной тестовой пересборки.

Конечно, идею метарепозитария можно редуцировать до отображения
ИМЯ_SRC_RPM_ПАКЕТА -> <СОБРАЛСЯ|НЕСОБРАЛСЯ>.
Но так мы не узнаем ничего интересного (о том, что там вообще собралось).

Я некоторое время назад начал делать как мне представляются подкаталоги
этого репозитария в giter-factory/build.gear.node.  Но есть много
вопросов по синхронизации архитектур и ещё кое-каких.

> Наверное, можно сохранять промежуточные состояния жизни транзакции, если
> это интересно.  Я пока не вижу, зачем это может понадобиться.

Для анализа промежуточных конфигураций, которые образуются в ходе
транзакции.

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

[devel] git-репозитарий для логов сборки

[Alexey Tourbin]

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

On Fri, Nov 09, 2007 at 01:08:40AM +0300, Alexey Tourbin wrote:
> > В моих рассуждениях было достаточно знать про каждый исходный пакет в
> > Сизифе Ra, собирался он или нет.  Зачем может быть нужно что-то ещё?
> 
> Ну например ты писал, что имеешь привычку сравнивать логи сборки
> пакетов.  Вот в метарепозитарии например можно хранить логи сборки
> пакетов.  Тогда систематическое сравнение логов сборки станет простой
> процедурой.
> 
> Хотя дело здесь не в логах, лог -- это плохой пример.

Кстати, логи можно складывать в отдельный git-репозитарий и публиковать
его!  git должен дать большую экономию по дисковому пространству.

В случае с логами видна одна проблема, котороя существует
и в метарепозитарии (точнее, в моей голове).

Нужно различать "начальный" и все последующие "тестовые" логи сборки.
Начальный лог сборки -- это тот лог сборки, который ФАКТИЧЕСКИ
соответствует собранному пакету в сизифе.  У нас ведь не принято
пересобирать пакеты просто так, то есть пмы не пересобираем пакет,
даже если при тестовой сборке в новой среде у него немного отличаются
зависимости (пока они не станут анметами).

Вопрос здесь в том, что для каждого пакета желательно отдельно хранить
начальный и все последующие тестовые логи сборки: log1 и log2.
При этом log1 создаётся один раз и навсегда для сборки данного релиза
пакета, а log2 обновляется при каждой тестовой пересборке.

Что это дает?  Сделав "diff -u log1 log2", мы увидим, чем отличается
фактический лог от последнего тестового.  Сделав же "git-whatchanged
-p log2", мы увидим, как изменялся log2 в процессе эволюции сборочной
среды.

Только здесь всё равно что-то не сходится.  "git-whatchenged -p log2"
будет работать "плоховато", в том смысле, что при каждом новом релизе
пакета log2 будет удаляться.

Поэтому упрощенный вопрос: как хранить логи сборки пакетов, с учетом
того, что желательно иметь простой способ отличать фактический лог от
тестового?  То есть какой должен быть расклад файлов/каталогов в
git-репозитарии логов сборки?  А с учетом предполагаемой синхронизации
основных архитектур?

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

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

[Dmitry V. Levin]

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

On Fri, Nov 09, 2007 at 01:08:40AM +0300, Alexey Tourbin wrote:
> On Fri, Nov 09, 2007 at 12:20:02AM +0300, Dmitry V. Levin wrote:
> > Транзакция состоит не просто из множества исходных пакетов, а из списка
> > исходных пакетов, т.е. это множество линейно упорядочено мантейнером.
> 
> В каком порядке заливать транзакцию gcc4.x + glibc?

В том порядке, который определил мантейнер.

> Есть небольшой риск, что сразу после фиксации транзакции либо gcc
> не будет собираться с glibc, либо glibc не будет собираться с gcc.

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

> Может быть это даже допустимо и в этом есть какой-то смысл.
> Но, в общем, внутри "атомарной" транзакции есть свои тонкости,
> она атомарна снаружи но не совсем атомарна внутри.

Ну да.  Можно собирать пакеты транзакции, пока этот процесс не сойдётся в
некотором смысле.  Хотя гарантий сходимости нет никаких.

[...]
> > Чем отличается критерий возможности rebase от критерия возможности сборки
> > вообще?  По идее, изменение Ra->Ra' можно преобразовать (rebase) в Ra->Rb',
> > если транзакцию A можно собрать на репозитории Rb.
> 
> Это тогда философский вопрос получается -- чем мёрж отличается от ребейса.
> Если и тот и другой одинаково возможны, то в результате у мёрж-коммита
> и ребейса будут одинаковые деревья, но разная история.

Лично я воспринимаю rebase как частный и довольно точно определённый вид
merge.  Я не вижу способа перенести git'овое представление термина
"merge by recursive" на нашу почву.

> > > > Из этого описания можно сделать выводы о том, что нужно для обработки
> > > > транзакции:
> > > > - бинарный репозиторий Сизиф для сборки пакетов;
> > > > - быстрое формирование нового бинарного репозитория Сизифа на основе
> > > >   предыдущего и новых пакетов (есть ли у нас необходимые средства?);
> > > 
> > > Насколько быстрое?
> > Быстрее чем среднее время сборки пакета.
> > > Думаю что достаточно быстрое имеется.
> > В каком виде?
> 
> Это грамотное удаление дупов + genbasedir.
> Несколько минут наверное.

Несколько минут это приемлемое время.

> > > По крайней мере, если новый репозитарий правильно сформирован, то
> > > 'apt-cache unmet' помогает обнаруживать бездумную/unintented смену
> > > сонейма.
> > 
> > Это отдельная проблема.  Просто она всплыла в процессе обдумывания, и я
> > отметил её.  В первом приближении можно пренебречь.
> 
> Не совсем понял.  Проблемами как раз пренебрегать нельзя.

В первом приближении можно, поскольку это не меняет сути дела.
Я утверждаю, что apt-cache unmet в нынешнем виде не отвечает на тот
вопрос, на который мы традиционно считали что отвечает.  Это не значит,
что мы не можем решать глобальную задачу сборки Сизифа, пока не решим
конкретную проблему apt-cache unmet.

> > > 30 минут на машине класса mash (см. мой query-rebuild.git).
> > > Но это может быть намного быстрее на каком-нибудь Core2Duo,
> > > и, следовательно, более приемлемо.
> > В машинах класса mash измерять уже не интересно, но 30 минут -- это
> > довольно много.
> 
> Да.  Это самое слабое место.  После того, как собрались пакеты
> транзакции, нужно ждать какое-то время, пока не просчитается список
> на тестовую пересборку.  Это время в среднем наверное превышает сборку
> поступивших пакетов + последующую тестовую пересборку.

Это можно обойти, не реализуя свой алгоритм обработки графа зависимостей,
без использования apt?

> > > Да.  Частью метарепозитария.  То есть нужно знать когда и в каком виде
> > > пакет последний раз собрался и кое-что ещё.
> > 
> > В моих рассуждениях было достаточно знать про каждый исходный пакет в
> > Сизифе Ra, собирался он или нет.  Зачем может быть нужно что-то ещё?
> 
> Ну например ты писал, что имеешь привычку сравнивать логи сборки
> пакетов.  Вот в метарепозитарии например можно хранить логи сборки
> пакетов.  Тогда систематическое сравнение логов сборки станет простой
> процедурой.

Принято.

> Хотя дело здесь не в логах, лог -- это плохой пример.
> Нужно хранить как минимум зависимости пакетов.  Зависимости пакета
> после очередной его тестовой пересборки могут отличаться -- сильно
> или не очень.  Это нужно обязательно знать иметь как бы "интерфейс"
> доступа к этой информации.  Сейчас единственный дурацкий дубовый
> интерфейс к этому делу называется qa-robot/cosubilode.  Им могут
> воспользоваться ограниченное число людей.  По сути никто не знает,
> как меняются зависимости у пакетов после очередной тестовой пересборки.
> 
> Конечно, идею метарепозитария можно редуцировать до отображения
> ИМЯ_SRC_RPM_ПАКЕТА -> <СОБРАЛСЯ|НЕСОБРАЛСЯ>.
> Но так мы не узнаем ничего интересного (о том, что там вообще собралось).

Логично.

> Я некоторое время назад начал делать как мне представляются подкаталоги
> этого репозитария в giter-factory/build.gear.node.  Но есть много
> вопросов по синхронизации архитектур и ещё кое-каких.

Давай их сюда.

> > Наверное, можно сохранять промежуточные состояния жизни транзакции, если
> > это интересно.  Я пока не вижу, зачем это может понадобиться.
> 
> Для анализа промежуточных конфигураций, которые образуются в ходе
> транзакции.

Какого рода анализа?


-- 
ldv

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

Re: [devel] git-репозитарий для логов сборки

[Dmitry V. Levin]

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

On Fri, Nov 09, 2007 at 01:30:12AM +0300, Alexey Tourbin wrote:
> On Fri, Nov 09, 2007 at 01:08:40AM +0300, Alexey Tourbin wrote:
> > > В моих рассуждениях было достаточно знать про каждый исходный пакет в
> > > Сизифе Ra, собирался он или нет.  Зачем может быть нужно что-то ещё?
> > 
> > Ну например ты писал, что имеешь привычку сравнивать логи сборки
> > пакетов.  Вот в метарепозитарии например можно хранить логи сборки
> > пакетов.  Тогда систематическое сравнение логов сборки станет простой
> > процедурой.
> > 
> > Хотя дело здесь не в логах, лог -- это плохой пример.
> 
> Кстати, логи можно складывать в отдельный git-репозитарий и публиковать
> его!  git должен дать большую экономию по дисковому пространству.

Особенно когда используется --nprocs=1.

> В случае с логами видна одна проблема, котороя существует
> и в метарепозитарии (точнее, в моей голове).
> 
> Нужно различать "начальный" и все последующие "тестовые" логи сборки.
> Начальный лог сборки -- это тот лог сборки, который ФАКТИЧЕСКИ
> соответствует собранному пакету в сизифе.  У нас ведь не принято
> пересобирать пакеты просто так, то есть пмы не пересобираем пакет,
> даже если при тестовой сборке в новой среде у него немного отличаются
> зависимости (пока они не станут анметами).
> 
> Вопрос здесь в том, что для каждого пакета желательно отдельно хранить
> начальный и все последующие тестовые логи сборки: log1 и log2.
> При этом log1 создаётся один раз и навсегда для сборки данного релиза
> пакета, а log2 обновляется при каждой тестовой пересборке.
> 
> Что это дает?  Сделав "diff -u log1 log2", мы увидим, чем отличается
> фактический лог от последнего тестового.  Сделав же "git-whatchanged
> -p log2", мы увидим, как изменялся log2 в процессе эволюции сборочной
> среды.
> 
> Только здесь всё равно что-то не сходится.  "git-whatchenged -p log2"
> будет работать "плоховато", в том смысле, что при каждом новом релизе
> пакета log2 будет удаляться.
> 
> Поэтому упрощенный вопрос: как хранить логи сборки пакетов, с учетом
> того, что желательно иметь простой способ отличать фактический лог от
> тестового?

Отличать лог фактической сборки от последующих тестовых можно с помощью
тэгов, например,
git log "$(git describe --abbrev=0)..HEAD"

> То есть какой должен быть расклад файлов/каталогов в
> git-репозитарии логов сборки?  А с учетом предполагаемой синхронизации
> основных архитектур?

Лог сборки - это свойство исходного пакета в данном репозитории для данной
архитектуры.  Например, это можно представить в виде
исходный_пакет/архитектура.


-- 
ldv

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

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

[Alexey Tourbin]

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

On Fri, Nov 09, 2007 at 01:38:50AM +0300, Dmitry V. Levin wrote:
> > Это тогда философский вопрос получается -- чем мёрж отличается от ребейса.
> > Если и тот и другой одинаково возможны, то в результате у мёрж-коммита
> > и ребейса будут одинаковые деревья, но разная история.
> 
> Лично я воспринимаю rebase как частный и довольно точно определённый вид
> merge.  Я не вижу способа перенести git'овое представление термина
> "merge by recursive" на нашу почву.

Merge -- полное сохранение истории, такой, какой она была, при том, что
в точке мёржа имеется "нематематический катаклизм".  В нашем случае этот
нематематический катаклизм можно сделать немного более математическим
за счёт фактического "перепроигрывания" (или же параллельного
дублирования) истории.  То есть стратегия мёржа в наших руках --
текстуального соответствия не требуется, а требуется выяснять
семантическую возможность мёржа.

Мёрж атомарен только в смысле подключения его к HEAD'у.
Сама по себе транзакция можно состоять из целого дерева коммитов.

Например, я отправил новую сборку perl-XML-LibXML, и сломался
perl-XML-LibXSLT.  Не дождавшись окончания тестовой пересборки,
я собрал libxml2.  Потом я получил результаты по perl-XML-LibXML
и взялся чинить perl-XML-LibXSLT.  Но libxml2 сам по себе уже прошёл
в HEAD.  Движение хеда на рисунке строго вертикальное.

	 /* merged perl-XML-LibXML with fixed perl-XML-LibXSLT
	* | perl-XML-LibXSLT built ok
	* | perl-XML-LibXML built ok against libxml2
	|\| branch is awaken by new perl-XML-LibXSLT 
	| * libxml2 built ok
	* | perl-XML-LibXSLT rebuild failed
	 `* perl-XML-LibXML built ok

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

Впрочем, я не против ребейса.
Я просто почему-то всегда думал про мёржи.
Теперь буду думать про ребейсы. :)

> В первом приближении можно, поскольку это не меняет сути дела.
> Я утверждаю, что apt-cache unmet в нынешнем виде не отвечает на тот
> вопрос, на который мы традиционно считали что отвечает.  Это не значит,
> что мы не можем решать глобальную задачу сборки Сизифа, пока не решим
> конкретную проблему apt-cache unmet.

Анметы можно маскировать кофликтами.
Над этим надо будет думать в другом треде.

> > Да.  Это самое слабое место.  После того, как собрались пакеты
> > транзакции, нужно ждать какое-то время, пока не просчитается список
> > на тестовую пересборку.  Это время в среднем наверное превышает сборку
> > поступивших пакетов + последующую тестовую пересборку.
> 
> Это можно обойти, не реализуя свой алгоритм обработки графа зависимостей,
> без использования apt?

Нет.  Не будет гарантии.  А тут нужна гарантия, то есть "полное
вычисление состояния".  Впрочем, гарантия не может быть сильнее,
чем воспроизводимость сборки пакетов.  Этим тоже надо заниматься
отдельно.

> > > Наверное, можно сохранять промежуточные состояния жизни транзакции, если
> > > это интересно.  Я пока не вижу, зачем это может понадобиться.
> > 
> > Для анализа промежуточных конфигураций, которые образуются в ходе
> > транзакции.
> 
> Какого рода анализа?

Мне интересно знать, что у кого сломалось и как они это чинили.

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

Re: [devel] git-репозитарий для логов сборки

[Alexey Tourbin]

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

On Fri, Nov 09, 2007 at 01:48:45AM +0300, Dmitry V. Levin wrote:
> Лог сборки - это свойство исходного пакета в данном репозитории для данной
> архитектуры.  Например, это можно представить в виде
> исходный_пакет/архитектура.

Точкой входа (top-level каталог) является имя src.rpm пакета.
типа
	.git/
	glibc/
	bash/
под каждым каталогом буедт что-то типа
	bash/
		SVR
		i586
		x86_64
это уже файлы; SVR -- это "чистая информация".  i586 и x86_64 --
это логи сборки.  Тут такая особенность, что мы не имеем права помещать
в репозитарий логи сборки от разных SVR, если речь идёт о синхронизации
основных архитектур.  И есть ещё эти неосновные архитетуры, которые не
нужно синхронизировать.  Если их как-то хранить, то опять усложняется
структура дерева фс.

Теперь к вопросу, как отличить фактический лог от тестового.
Косвенным признаком может стать изменение файла SVR.  Когда
файл SVR изменился, то в этом месте логи фактические,
а во всех случаях они тестовые.  Но этот признак плохо
соседствует с "неосновными архитектурами".

На это наслаивается ещё одна проблема.  Желательно уметь формально
отличать "успешные" логи сборки (зелёные) от "неуспешных" (красных).
Как сохранить информацию красный/зелёный (без заглядывания в лог)?
Фактические логи по определению всегда успешные (при синхронизации
архитектур), а статус тестовых логов i586 и x86_64 при очередной
тестовой пересборке может между собой отличаться.

То есть проблема такая: если брать примитивную структуру фс,
то реализация элементарных операций становится более сложной.
А более просто реализовать элементарные операции можно только
за счёт серьёзного усложнения структуры фс (так что метарепозитарий
становится интуитивно непонятным).

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

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

[Alexey Tourbin]

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

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'ы ведут себя
разумно.)  Но это уже политика, кому давать а кому не давать.
С ребейсом, кажется, посложнее это будет сделать.

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

Re: [devel] git-репозитарий для логов сборки

[Dmitry V. Levin]

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

On Fri, Nov 09, 2007 at 02:28:31AM +0300, Alexey Tourbin wrote:
> On Fri, Nov 09, 2007 at 01:48:45AM +0300, Dmitry V. Levin wrote:
> > Лог сборки - это свойство исходного пакета в данном репозитории для данной
> > архитектуры.  Например, это можно представить в виде
> > исходный_пакет/архитектура.
> 
> Точкой входа (top-level каталог) является имя src.rpm пакета.
> типа
> 	.git/
> 	glibc/
> 	bash/
> под каждым каталогом буедт что-то типа
> 	bash/
> 		SVR
> 		i586
> 		x86_64
> это уже файлы; SVR -- это "чистая информация".  i586 и x86_64 --
> это логи сборки.  Тут такая особенность, что мы не имеем права помещать
> в репозитарий логи сборки от разных SVR, если речь идёт о синхронизации
> основных архитектур.  И есть ещё эти неосновные архитетуры, которые не
> нужно синхронизировать.  Если их как-то хранить, то опять усложняется
> структура дерева фс.

Если разнести разные архитектуры не по каталогам, а по бранчам, тогда
можно избавиться от необходимости синхронизации.

> Теперь к вопросу, как отличить фактический лог от тестового.
> Косвенным признаком может стать изменение файла SVR.  Когда
> файл SVR изменился, то в этом месте логи фактические,
> а во всех случаях они тестовые.  Но этот признак плохо
> соседствует с "неосновными архитектурами".

Ещё раз предлагаю ставить тэги на логи "настоящих" сборок.

> На это наслаивается ещё одна проблема.  Желательно уметь формально
> отличать "успешные" логи сборки (зелёные) от "неуспешных" (красных).
> Как сохранить информацию красный/зелёный (без заглядывания в лог)?
> Фактические логи по определению всегда успешные (при синхронизации
> архитектур), а статус тестовых логов i586 и x86_64 при очередной
> тестовой пересборке может между собой отличаться.

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


-- 
ldv

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

Re: [devel] git-репозитарий для логов сборки

[Alexey Tourbin]

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

On Fri, Nov 09, 2007 at 04:09:12AM +0300, Dmitry V. Levin wrote:
> Если разнести разные архитектуры не по каталогам, а по бранчам, тогда
> можно избавиться от необходимости синхронизации.

А надо ли от неё избаляться, и на каком уровне?  К тому же,
"бранчи" я зарезервировал не для архитектур, а для входящих
пакетов.  То есть бранч "форкается" на каждый входящий пакет,
а не по архитектурам.

> > Теперь к вопросу, как отличить фактический лог от тестового.
> > Косвенным признаком может стать изменение файла SVR.  Когда
> > файл SVR изменился, то в этом месте логи фактические,
> > а во всех случаях они тестовые.  Но этот признак плохо
> > соседствует с "неосновными архитектурами".
> Ещё раз предлагаю ставить тэги на логи "настоящих" сборок.

Таг -- это менее надёжно, хочется чтобы всё было зашито в самом дереве
коммитов.  Хотя конечно тоже вариант.

> > На это наслаивается ещё одна проблема.  Желательно уметь формально
> > отличать "успешные" логи сборки (зелёные) от "неуспешных" (красных).
> > Как сохранить информацию красный/зелёный (без заглядывания в лог)?
> > Фактические логи по определению всегда успешные (при синхронизации
> > архитектур), а статус тестовых логов i586 и x86_64 при очередной
> > тестовой пересборке может между собой отличаться.
> 
> Т.е. ты хочешь вместе с логами хранить некоторые их атрибуты, которые
> можно будет увидеть, не заглядывая в логи?
> Попробуй поместить эти атрибуты в файлы по соседству.

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

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

Re: [devel] git-репозитарий для логов сборки

[Alexey Tourbin]

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

On Fri, Nov 09, 2007 at 01:48:45AM +0300, Dmitry V. Levin wrote:
> Отличать лог фактической сборки от последующих тестовых можно с помощью
> тэгов, например,
> git log "$(git describe --abbrev=0)..HEAD"

А будет ли это работать?
То есть это же всего один репозитарий с подкаталогами!
	.git/
	glibc/
	bash/
	...

Монолитный, а не для каждого отдельного пакета!

Мне нужно узнать напр. последний таг проставленный В СВЯЗИ
С ИЗМЕНЕНИЕМ каталога bash/.

То есть при ребейсах дерево будет

				* test rebuild .../
				* test rebuild bash/ 3.1-alt1
	[tag:glibc-2.7-alt0]	* initial build glibc/ 2.7-alt0
	[tag:bash-3.1-alt1]	* initial build bash/ 3.1-alt1

Как вытащить последний таг в связи с изменением определённого каталога?

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

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

[Kirill A. Shutemov]

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

On [Fri, 09.11.2007 04:06], Alexey Tourbin wrote:
> Значит, простейшая дерево метарепозитария -- это что-то типа
> 	.git/
> 	glibc/
> 		SVR
> 		i586/
> 			BuildRequires
> 		x86_64/
> 			BuildRequires
> 	bash/
> 		...

Может лучше внести SVR внутрь %arch? Тогда можно допустить
рассинхронизацию для неосновных архитектур. Проверить что нужные
архитектуры синхронизированы можно внешним инструментом.

-- 
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 --]