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

Sergey Vlasov =?iso-8859-1?q?vsu_=CE=C1_altlinux=2Eru?=
Чт Ноя 8 21:38:16 MSK 2007


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


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