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

[Dmitry V. Levin]

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
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20071109/18682032/attachment-0002.bin>