[devel] [JT] Re: Incoming rebuilds

[Денис Смирнов]

On Wed, Sep 01, 2004 at 01:33:03AM +0400, Dmitry V. Levin wrote:

 >> Просто моя идея не получила хотя бы одобрения со стороны inger@ и ldv@, а
 >> как я понимаю, это от них зависит пойдёт ли мой скрипт в /dev/null.
 DVL> Напомните ссылку на всякий случай, может кто-то пропустил.

Сейчас не найду (я не тонком диалапе сейчас). Это был дли-и-и-и-инный
тред, в котором основными "зачинщиками" были мы с Михаилом Шигориным. Там
засветились все, в том числе inger@ и ты.

 >> Кроме того технология в том виде, в котором её представлял я -- _требует_
 >> выделеной машины, которая будет практически непрерывно пытаться собрать
 >> полученые пакеты.
 DVL> Непрерывно? :)

После каждого добавления нового пакета он будет немедленно пытаться
собраться. Если собрался -- будет попытка пересборки всего что валяется в
очереди.

>> Судя по тому, что я прочитал в тезисах конференции на Протве (увы, туда я
>> доехать не смог) основную предлагаемую мной функциональность как раз уже
>> реализовали.
>> 
>> Я так и не понял, на каком этапе вмешивается конкретно сейчас (после
>> переделок) сам incominger@ в процесс. В моём представлении он вмешивается
>> исключительно после того, как пакет уже проверен на пересобираемость
>> и.т.д, и только в том случае, если сменился мантейнер или список бинарных
>> пакетов, генерируемых из этого, ну или если это совсем новый пакет.
 DVL> Цикл пересборки сейчас активируется вручную и выглядит (должен выглядеть)
 DVL> примерно следующим образом:
 DVL> 1. Проверяются пакеты, подлежащие пересборке:
 DVL>   - пакеты, не прошедшие sisyphus_check, отбраковываются, а сделавшие их
 DVL>     maintainerы (если их удалось установить) уведомляются;

А зачем для допуска к этому этапу ручная активация процесса?
 
 DVL>   - новые пакеты, а также пакеты, сделанные не теми maintainerами, которые
 DVL>     зарегистрированы для соответствующих пакетов, отправляются incomingerу
 DVL>     на approval;

Сие должно быть вручную.
 
 DVL>   - все остальные пакеты отправляются на сборку.

Опять же, а здесь почему не автоматика?

 DVL> 2. Пакеты пересобираются:
 DVL>   - пакеты, подлежащие пересборке, разбиваются на группы: каждую группу
 DVL>     составляют все пакеты, собранные одним и тем же maintainerом;
 DVL>   - пакеты в каждой из групп пересобираются отдельно, в порядке увеличения
 DVL>     даты сборки в режиме --with-stuff;

Ага.

 DVL>   - непересобравшиеся пакеты в каждой группе отправляются на повторную
 DVL>     пересборку;  процесс пересборки группы пакетов заканчивается, когда либо
 DVL>     не остается непересобравшихся пакетов, либо их число не уменьшается.

Логично.

 DVL>   - логи сборки непересобравшихся пакетов (точнее говоря, хвосты логов)
 DVL>     отправляются maintainerам соответствующих пакетов.

Угумс. Хотя насчёт только хвостов -- зря. Хорошо бы и сами логи
выкладывать куда-нибудь в rsync'о доступное место (чтобы был виден,
например, вывод configure).

 DVL> 3. Пересобранные пакеты проверяются:
 DVL>   - пакеты, комплектация (набор подпакетов) которых изменилась,
 DVL>     отправляются incomingerу на approval;

Логично.
 
 DVL>   - остальные пакеты отправляются в репозитарий, заменяя предыдущие сборки
 DVL>     этих пакетов.
 DVL> 4. В конце дня incominger делает заключительную проверку:
 DVL>   - пересобирается пакет altlinux-release; неудача пересборки
 DVL>     свидетельствует о непригодности репозитария; виновные в этом
 DVL>     безобразии обычно быстро вычисляются, дальнейшие действия по
 DVL>     обстоятельствам;

Что значит "непригодность репозитария"?
 
 DVL>   - сравнивается вывод "aptbox/apt-cache unmet" с предыдущим днём;
 DVL>     при появлении новых unmetов репозитарий может быть признан непригодным;
 DVL>     заинтересованные в информации о новых unmetах уведомляются.

Ясно.

Спасибо за подробное разъяснение.

-- 
С уважением, Денис

http://freesource.info