On Tue, Apr 17, 2007 at 05:31:45PM +0400, Dmitry V. Levin wrote:
> On Tue, Apr 17, 2007 at 05:29:39AM +0400, Alexey Tourbin wrote:
> > А есть какие-нибудь наброски не тему реализации build?
> 
> Все наброски, которые у меня есть, находятся в
> git.alt:/people/ldv/packages/girar.git
> 
> Но там по поводу сборки почти ничего нет.
> 
> У тебя есть идеи?

Мы обсуждали с AMorozov на канале, как организовать полную regression
пересборку сизифа при прохождении каждого отдельного пакета.
Естественно, пересобирать нужно не всё, а только те пакеты, которые
как-либо зависят он вновь пришедшего пакета.

Точнее алгоритм regression переcборки такой:

1) учитываем все подпакеты вновь пришедшего пакета;
2) инициализируем query-buildroot с учетом поступивших подпакетов;
3) если какой-либо подпакет входит в basesystem+rpm-build, т.е. встал
в query-buildroot, тогда организуется низкоприоритетная очередь
"пересобрать весь сизиф"; дальше это не рассматривается; точнее,
содержимое query-билдрута не учитвается;
4) query-buildroot в который встал basesystem+rpm-build я далее называю
query-песочницей, или просто песочницей.  Теперь нужно *каждый* src.rpm
пакет пробить по песочнице в смысле print_uris, чтобы посмотреть, не
встанет ли в buildroot при его сборке какой-либо вновь учтенный пакет;
5) если обнаруживается, что для сборки очередного src.rpm пакета в
buildroot нужно поставить некоторые из только что учтенных пакетов,
тогда src.rpm пакет является предметом regression пересборки.

В итоге должны пересобираться все src.rpm пакеты, такие что в buildroot
у них встает один из вновь прибывших подпакетов.

Здесь есть две проблемы:

1) query песочницы обходится порядка одной секунды.  Если пробивать по
песочнице порядка 6000 src.rpm пакетов, то на каждый входящий пакет
придётся квирить песочницу порядка двух часов.

Мы обсудили с AMorozov что алгоритм замыкания зависимостей находится в
apt-get.cc; и что этот алгоритм, вообще говоря, не реентерабельный,
поскольку модифицирует глобальную структуру данных Cache.  Т.е. не
существует простого способа (в цикле) существенно снизить время запроса
к песочнице.

2) Ещё хуже.  На самом деле нет готовых src.rpm пакетов, по которым
можно квирить песочницу.  Есть только git репозитарии.  Запуск gear и
создание pkg.tar, который можно будет полноценно проквирить, обойдется
ещё в какое-то время.  Хуже того, полноценный квиринг pkg.tar
подразумевает постепенной наращивание билдрута (различие между
BuildRequires и BuildRequires(pre)).  То есть, грубо говоря, нужно
"начать собирать" пакет, чтобы понять, нужны ему какие-либо из вновь
учтенных пакетов или нет.

То есть вопрос который мы обсуждали на канале стоит так: в сизиф прошел
новый пакет (в виде подпакетов).  Какие теперь пакеты подлежат
пересборке в тестовых целях (с новым пактом, в виде подпакетов)?

Как я уже писал, существует более простая модель.  Можно просто
сохранять билдлог предыдущей сборки и проверять по этому логу что
становится в билдрут.  Но это не разрешает проблемы Provides+Obsolets.
Например пришел пакет libstdc++4.2, а в старых логах libstdc++4.1, тогда
нет хорошего способа сказать, что вместо libstdc++4.1 теперь apt
поставит libstdc++4.2, и результат может кардинально измениться.

В общем, трудная проблема.