On Wed, Mar 11, 2009 at 10:53:49PM +0300, Денис Смирнов wrote:
> On Tue, Mar 10, 2009 at 10:47:17PM +0300, Алексей Турбин wrote:
> 
> AT> Изменения могут пройти задним числом, потому что рантайм зависимости
> AT> обновляются помимо нашего желания.  Например, если завтра glibc
> AT> обновится, то все пакеты можно будет тестировать заново (вручную,
> AT> если проверять работоспособность).
> 
> Алексей. Ты с собеседниками в этой ветке не понимаете друг-друга из-за
> разной позициии восприятия -- со стороны системшика и со стороны
> прикладников и админов.

Disclaimer: я не единственный разработчик сборочной системы.  ldv тоже
разработчик сборочной системы, и он реализовал часть используемых сейчас
возможностей (против некоторых из которых я бы возражал, но не настолько
сильно, чтобы ставить всё дело под вопрос).  На самом деле, окончательные
решения принимает именно он.

Но в основе сборочной системы лежат идеи (изложенные в тезисах моего
доклада), которые вряд ли претерпят существенные изменения.
ftp://ftp.altlinux.org/pub/people/at/protva-2008.pdf

А именно, сборочная система работает так:
1) Собирает пакеты, которые её просят собрать.
2) Формирует новый репозитарий (во временном каталоге).
3) Вычисляет характеристики текущего репозитария и нового репозитария.
4) Если характеристики ухудшились, то пакеты отвергаются.
5) Если характеристики не ухудшились, то пакеты проходят (новый временный
репозитарий становится текущим).

Далее система переходит в начальное состояние -- ждет, что кто-то
попросит собрать её новые пакеты.  Это уже будет на новом репозитарии
(если предыдщие пакеты прошли).

"Характеристики репозитария" изначально не детализируются.
Исчерпывающие характеристики репозитария -- это всё, что можно проверить
автоматически, начиная от анметов и кончая регрессией по тестовой
пересборке пакетов.  (Проблема в том, что на стадии вычисления
характеристик мы очень ограничены по времени.  Несколько минут нам как
бы дано естественным образом, а если мы не укладываемся, то надо что-то
придумывать и, например, переводить задание в отложенный режим.  Короче,
это уже детали, которые интересны только разработчикам сборочной системы.)

Мне кажется, что эти идеи настолько просты, прозрачны и справедливы, что
лучше что-либо придумать просто нельзя.  Это если мы хотим поддерживать
целостный репозиатрий, а не хранилище файлов с расширением *.rpm.

> Далеко не все ошибки в ПО так или иначе связаны с окружением. Я склонен
> считать что большая часть ошибок в _моем_ коде проявятся вне зависимости
> от версии glibc, ибо являются ошибками в логике самой программы.
> 
> И подобные ошибки можно (и нужно) ловить ручным тестированием, к
> сожалению. Либо покрывать всю программу целиком юнит-тестами. Выполнить
> второе для всех приложений в Сизифе -- невозможно, остается только ручное
> тестирование.

Окей, давайте искать примирения.  Что могут сделать разработчики
сборочной системы, если не решить все проблемы за счет создания
полумифической "инфраструктуры" или "фреймворка"?

Можно сделать следующее:

1) Реализовать manual-режим подтверждения заданий.
Его уже частично реализовал ldv.

2) В самом задании формировать каталог RPMS.hasher, который будет
доступн через напр. git.altlinux.org::tasks/N/hasher/repo/RPMS.hasher.