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

[Alexey Tourbin <at@altlinux.ru>]

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