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

[Dmitry V. Levin]

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
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?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/9debd75f/attachment-0002.bin>