[devel] RFC: тестирование входящих пакетов полной пересборкой сизифа

[Alexey Tourbin]

Я заметил, что branch 4.0 перед выкладыванием проходит тестирование
пересборкой.  Всё это делается вручную.  У меня есть предложение
внедрить аналогичную схему _автоматической_ пересборки для сизифа.

Я систематизирую идеи, которые обсуждал на конференции с ldv.
К сожалению, мне не удалось обсудить это с legion'ом.

Предыдущее обсуждение этой же темы здесь:
http://lists.altlinux.org/pipermail/devel/2007-April/045149.html
http://lists.altlinux.org/pipermail/devel/2007-April/045288.html
(и вообще все письма в этом треде -- "git.alt build")

Основная идея в том, что на каждый входящий пакет можно устраивать
полную пересборку сизифа с этим пакетом (если он собрался).  Это нужно
для "раннего" обнаружения проблем, чтобы не пропускать в сизиф пакеты,
которые заведомо слишком много ломают (по крайней мере, в смысле
возможности пересборки пакетов).

Любая попытка провести новый пакет (новую сборку пакета) в сизиф должна
быть, вообще говоря, "условной" (или "пробной").  После того, как пакет
собрался, нужно провести "полную пересборку сизифа" с этим пакетом.
Если все пакеты "успешно пересобрались", то новая сборка автоматически
проходит в сизиф.  Если же некоторые пакеты сломались, то новая сборка
ставится "на подтверждение".

Поясню некоторые выражения в кавычках.

"Полную пересборку сизифа" следует трактовать не буквально, а вот как:
пересобрать все пакеты, у которых при сборке в билдрут ставится один из
новых пакетов.  Это означает, что, с учетом поступивших пакетов, для
каждого src.rpm пакета формируется список пакетов для билдрута.  Если в
списке пакетов для билдрута оказывается новый пакет, то этот src.rpm
пакет подлежит пересборке.

"Успешная пересборка" сизифа подразумевает сравнение с предыдущим
статусом "полной пересборки сизифа".  Если по сравнению с предыдущей
полной пересборкой какой-либо пакет перестал собираться, значит,
пересборка не является успешной.

"Подтверждение" означает осознанное действие со стороны maintainer'а
пакета и/или "формирующего очередной релиз сизифа" по отношению к
пакету, который что-то сломал.  То есть можно вручную подтвердить,
что новый пакет всё же не настолько плох, чтобы не пускать его в сизиф
(например, виноваты другие пакеты, или же ожидается их скорое
исправление).

Вижу две проблемы: теоретическую (сериализация) и ресурсы.

Сериализация.  В идеале таким образом пакеты должны идти в очередь один
за другим, и очередь не должна двигаться, пока не будет принято решение
по каждому очередному "неидеальному" пакету.  К сожалению, полная
сериализация будет упираться в человеческий фактор (подтверждение
вручную) и поэтому нетехнологична.  То есть проблема в том, что
параллельно протестированные пакеты могут по отдельности ничего не
ломать, а комбинация двух новых пакетов может дать уже другой исход.
Пример.  Прошел пакет libxml2 и успешно протестировался пересборкой
старой версии perl-XML-LibXML.  Параллельно прошел новый пакет
perl-XML-LibXML и успешно протестировался на старой версии libxml2.
Но, может статься, новый perl-XML-LibXML уже не будет собираться
на новой версии libxml2.

На самом деле такого рода "конкурентные изменения" рассматриваются
в теории RDBMS.  Там есть разные уровни изоляции транзакций и т.д.
Может кто знает.

Ресурсы.  На самом деле для "среднего пакета" потребуется не слишком
много сборочных ресурсов.  Недавно я выяснил (и написал), что число
пакетов в сизифе, у которых в билдруте при сборке есть библиотека
libcurl, это число равно 69 (если не ошибаюсь).

Конечно, если пакет ставится в базовую сборочную среду, тогда
возможность уменьшения списка пакетов исчезает.  Но, может быть,
кто-нибудь помнит историю с битым cpio ("cpio обновился, и hasher
сломался").  Так что ресурсы на полную пересборку сизифа при прохождении
базовых пакетов не стоит считать потраченными напрасно.

Впрочем, последнее мнение не отменяет вопроса о наличии ресурсов как
таковых.

Техническая проблема на подступах к определению списка пакетов, подлежащих
пересборке, было в том, что нужно научиться очень быстро строить список
пакетов в билдруте при сборке каждого src.rpm пакета.  Стандартный
способ (который используется в hasher, через --print-uris) занимает
порядка одной секунды на src.rpm пакет.  Это связано с тем, что apt всё
время перечитывает свой кеш.  В сизифе около 6000 src.rpm пакетов, значит,
определять, какие из них нужно пересобрать, можно около 2 часов.  Это
даже больше, чем может занять последующая пересборка обнаруженным таким
образом src.rpm пакетов.  У меня сейчас зреет решение, как немного
захачить апт и написать к нему скрипт на lua, чтобы построение списка
пакетов для пересборки по времени сводилось к чтению хедеров src.rpm
пакетов.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20070822/00f6821e/attachment-0001.bin>