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

[Alexey Tourbin]

On Sat, Aug 25, 2007 at 02:16:46PM +0400, Alexey I. Froloff wrote:
> * Alexey Tourbin <at@> [070825 13:40]:
> > Разруливать, по-моему, должен не столько товарищ, сколько maintainer.
> > То есть ему через несколько часов приходит письмо: "ой-ой-ой, вы
> > ДЕЙСТВИТЕЛЬНО хотите отправить это дело в сизиф"?  И maintainer
> > отвечает: "да-да-да, я знаю, исправленные пакеты почти готовы".
> Это АЦЦКИ медленно.  Вот, например, thresh@ залил новый FLAC со
> сменой API и одновременно NMU на несколько зависимых пакетов.
> Или либа с новым SONAME и compat пакет.  Если их перемещать по
> одному, то будут новые unmet'ы в репозитарии и сломанная сборка.
> Ждать ещё по несколько часов для каждого пакета?

Я рассматриваю более пессимистическую ситуацию: maintainer направляет
новый пакет и НЕ ЗНАЕТ, как изменятся характеристики сизифа на этом
пакете.  Ответственный maintainer, который заранее подготовил NMU,
это хорошо, но технологичность должна подразумевать защиту от сбоев
по пессимистическому сценарию.

Опять же, я не против транзакции из нескольких пакетов, если все они
проводятся одним человеком.  Однако NMU настораживает.  Техника
получения NMU до конца не отработана.

Насчет "будет медленно" не очень согласен.  Входящий flac-*.src.rpm
сейчас "задевает" 161 пакет, включая те приложения в которых FLAC для
сборки по сути и не используется (а ставится только одна только
библиотека libflac).

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

Дело в том, что нужно уметь ответить на вопрос: КТО именно и ЗА СЧЕТ
ЧЕГО именно сломал ЭТОТ пакет (который перестал собираться).  Чем меньше
будет неопределенности, тем лучше (будет понятно, что нужно откатывать,
или хотя бы кого трясти).

С другой стороны, хотелось бы, конечно, обеспечивать атомарную смену
soname'ов в репозитарии.  Но при числе вовлеченных maintainer'ов больше
2-3 это становится проблемно...

Кстати смену soname'ов можно обнаруживать автоматически.  Просто нужно
сравнивать зависимости у пакетов, свежепротестированных пересборкой,
и уже собранных пакетов.

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

К сожалению, работа управдома для меня достаточно непрозрачна, и,
насколько я знаю, нигде на git.altlinux.org управдомовские скрипты
не публикуются.

Плюс есть ещё параллельные транзакции.  От них ЗЕЛО голова болит, я их
пока даже не обсуждал.  Грубо говоря, начиная говорить о транзакциях,
есть два подхода.  Первый подход -- каждый пакет собирается и
тестируется на логически "приватной копии" Сизифа.  То есть каждый
входящий src.rpm пакет берёт "длинный" read-lock на текущий сизиф, а
"сводильщик" будет работать в режиме writer starvation.  Другой крайний
вариант -- один большой общий отстойник для всех, который может
полностью или частично перемещаться в сизиф.  Кстати это не настолько
глупо, как может показаться с первого взгляда.  Промежуточный вариант --
изоляция на уровне maintainer'а.  Ну и что будет если при сведении
"сводильщик" обнаруживает пересечения, тоже непонятно.  Ладно, это уже
вопросы на более отдалённое будущее, когда основные проблемы будут
решены.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?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/20070825/6c09ccee/attachment-0001.bin>