On Thu, Feb 26, 2009 at 03:50:45PM +0200, Igor Vlasenko wrote:
> On Thu, Feb 26, 2009 at 04:43:03PM +0300, Alexey Tourbin wrote:
> > Дьявол в деталях.  Мне кажется, что нельзя двигаться вперёд, оставляя
> > после себя шлейф разломанных пакетов.  На самом деле в новейшей истории
> > ни разу не удалось естественным образом достичь ситуации, когда число
> > разломанных пакетов было бы на допустимом минимальном уровне (грубо
> > говоря, не больше, чем несколько штук).  Всё время было много анметов
> > и всё время пакеты сотнями не собирались.  И весь этот фриз когда осенью
> > или весной начинают закручивать гайки это какое-то робкое гоняние с
> > палкой за людьми.  И более приемлемое состояния в конечном счете
> > удавалось добиться лишь за счёт удаления пакетов.
> 
> Об этом и речь.
> Как это реально будет выглядеть?
> Будет ли это похоже на pocket, о котором говорил Денис?

Сейчас есть проблема похуже: в одном задании нельзя совместить
gear-репозитарии и src.rpm пакеты.  Это значит, что если
gear-репозитарий ломает src.rpm пакет, или src.rpm пакет ломает
gear-репозитарий, то пока ничего сделать нельзя (точнее, можно
форсировать сборку src.rpm пакета из gear-репозитария, но этим
src.rpm пакет навсегда конвертируется в gear-репозитарий).

В остальном, работать это будет, видимо, так: есть текущий статус
пересборки всех пакетов (какие пакеты не пересобираются).  Приходит
новый пакет, вычисляется новый статус пересборки (пересобираются все
зависимые пакеты).  Если пересборка каких-то пакетов сломалось, то новый
пакет по умолчанию не проходит.  Можно контролируемо допускать разлом
пересборки, примерно так же, как сейчас можно контролируемо нарушать
ACL/подтверждать NMU.  В отличие от NMU, нет ясного понимания, кто
сможет допускать разлом пересборки.  Видимо, только пользователь
girar_root; он же мейнейнер пакета gcc (получается нехорошо...).

> И как работать в рамках одной транзакции
> с набором разных gcc 
> gcc 3.3-althack1, set of fixes 1, ...gcc 3.3-althack2,... fix2,... 
> gcc 3.3-althackN, fixes N ?

Нет, никаких разных gcc в пределах одного задания не будет.
Я имел в виду подход попроще: сначала максимально забить gcc4.4 хаками,
чтобы не было поломок пакетов по косметическим причинам.  Когда новый
gcc пройдёт, собирать новые релизы gcc, в которых по одному эти хаки
отрывать, и чинить отвалившиеся пакеты.