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

[Alexey Tourbin]

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.  Но есть много
вопросов по синхронизации архитектур и ещё кое-каких.

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

Для анализа промежуточных конфигураций, которые образуются в ходе
транзакции.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?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/08e7551e/attachment-0002.bin>