Re: [devel] git.alt build

[Alexey Tourbin <at@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 3115 bytes --]

On Sat, Apr 21, 2007 at 02:25:47AM +0400, Dmitry V. Levin wrote:
> > То есть, как бы философски, это разница между знанием и невежеством.
> > Я отправил в сизиф новую сборку перла и я не знаю, сломает она
> > что-нибудь или нет.  Нужно ждать неделю или две, когда пройдет очередная
> > пересборка, тогда станет ясно.  С другой стороны, если бы я заранее
> > знал, что будут некоторые проблемы, то я, быть может, и не отправил бы
> > такую сборку в сизиф.
> 
> И как ты предлагаешь этот вопрос решать?  Автоматически тестировать
> пересборку всего, чтобы определить, пропускать ли новую сборку перла в
> Сизиф, конечно, было бы здорово, если бы это тестирование не было столь
> ресурсоёмким.

Ресурсы дело наживное.  Для начало нужно научиться быстро определять,
какие пакеты подлежат пересборке.  За вычетом perl-base получится
несколько сотен пакетов.  Среднее время сборки пакета, очень грубо,
около одной минуты.  Без распараллеливания получается несколько часов.
Туговато.

$ grep '^perl-[^b].*-5.8.8-alt10$' -l -r success error |wc -l
1341
$

Даже если управляться с каждым входящим пакетом за час, то получается
пропускная способность около 24 пакетов в сутки.  Нужно бы поточнее
статистику прикинуть.

И, конечно, не понятно, что делать, если обнаружено, что входящий пакет
что-либо ломает.  Очередь встаёт, пока человек не ответит да/нет.

С другой стороны, полная regression пересборка у нас всё равно проходит,
так что затраты по ресурсам сопоставимы.  Просто при полной regeression
пересборке "схлопываются" зависимости, то есть нельзя определить, какой
именно пакет сломал сборку данного пакета (если в билдруте поменялось
более одного пакета).

> > > Впрочем, и последнее выглядит более ресурсоёмким, чем (в среднем) сборка
> > > одного пакета.
> > 
> > Что ты понимаешь под install regression?  Какие комбинации пакетов надо
> > тестировать на установку?
> 
> install regression -- это такая ситуация: пакет A раньше устанавливался,
> а теперь перестал устанавливаться.  Например, если у пакета A появился
> unmet, то это install regression.

То просто попробовать установить все пакеты сизифа после прохождения
очередного пакета?

Или же просто попробовать установить сами собранные пакеты, и если они
устанавливаются, тогда нет причин думать, что и другие пакеты, которые
их требуют, не будут устанавливаться?

Последнее реализовать довольно просто.  Можно прямо в сборочный
buildroot попробовать поставить свежесобранные пакеты через rpm -Uv.
Мне пока не приходят в голову "легальные" случаи, когда такая установка
может не пройти.  То есть сборочные зависимости пакета я вижу как
надмножество установочных зависимостей.  Ну или аптом ставить, если
выяснится, что в ряде случаев это предположение неверно.  Прямо в hasher
бы такую штуку вделать.

> Есть множество пакетов, для которых пересборочный тест является основной
> характеристикой работоспособности.  Но в это множество попадает не так
> много пакетов.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]