[devel] git.alt build
Alexey Tourbin
=?iso-8859-1?q?at_=CE=C1_altlinux=2Eru?=
Сб Апр 21 03:09:09 MSD 2007
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
бы такую штуку вделать.
> Есть множество пакетов, для которых пересборочный тест является основной
> характеристикой работоспособности. Но в это множество попадает не так
> много пакетов.
Но это лучшее, что у нас есть для "раннего" автоматеческого
тестирования, без привлечения квалифицированных тестеров.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : =?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/20070421/b774246b/attachment-0001.bin>
Подробная информация о списке рассылки Devel