On Wed, Apr 18, 2007 at 08:05:58AM +0400, Alexey Tourbin wrote:
> Мы обсуждали с 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, и результат может кардинально измениться.

В query-rebuild.git есть вариант, как можно проквирить *.src.rpm и
отсеить те из них, которые нуждаются в тестовой пересборке.  Это всё
равно занимает достаточно много времени (несколько минут), но не
паталогически много времени.  И здесь всё ещё нельзя отказаться от
src.rpm.  Чтобы отказаться от src.rpm нужно "кешировать" BuildRequires.