Re: [devel] git.alt build

["Dmitry V. Levin" <ldv@altlinux.org>]

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

On Sat, Apr 21, 2007 at 02:00:38AM +0400, Alexey Tourbin wrote:
> On Sat, Apr 21, 2007 at 01:44:06AM +0400, Dmitry V. Levin wrote:
> > > Мы обсуждали с AMorozov на канале, как организовать полную regression
> > > пересборку сизифа при прохождении каждого отдельного пакета.
> > 
> > Если целью является сборочная система, функционирующая без участия
> > человека (с минимально возможным участием человека), то к ней лучше
> > приближаться постепенно.
> 
> Без человека это функционировать не может.

Я имею в виду систему, которая в идеале функционирует без
человека-смотрителя, а на практике вмешательство человека-смотрителя
минимально.

> То есть, как бы философски, это разница между знанием и невежеством.
> Я отправил в сизиф новую сборку перла и я не знаю, сломает она
> что-нибудь или нет.  Нужно ждать неделю или две, когда пройдет очередная
> пересборка, тогда станет ясно.  С другой стороны, если бы я заранее
> знал, что будут некоторые проблемы, то я, быть может, и не отправил бы
> такую сборку в сизиф.

И как ты предлагаешь этот вопрос решать?  Автоматически тестировать
пересборку всего, чтобы определить, пропускать ли новую сборку перла в
Сизиф, конечно, было бы здорово, если бы это тестирование не было столь
ресурсоёмким.

> > Мне кажется, что тестирование на предмет build regression более
> > ресурсоёмкое, чем тестирование на предмет install regression.
> 
> По крайней мере новая схема сборки пакетов должна быть достаточно
> гибкой, чтобы при достаточном количестве ресурсов такую regression
> пересборку можно было делать.

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

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

install regression -- это такая ситуация: пакет A раньше устанавливался,
а теперь перестал устанавливаться.  Например, если у пакета A появился
unmet, то это install regression.

> > Единственный метод, который у нас есть, базируется на
> > "apt-cache unmet" и является очень ресурсоёмким в части формирования
> > индексов временного репозитория.
> 
> По поводу unmet'ов тоже есть некоторые мысли.  Не все unmet'ы одинаково
> критичны.  Их нужно взвешивать по количеству пакетов, которые с
> появлением данного анмета становится невозможным установить.

Это значит, что часть unmet'ов можно обрабатывать автоматически, без
привлечения человека-смотрителя.

> Например, если unmet появился в пакете perl-base, то это очень-очень
> плохой unmet; а если unmet появился в пакете perl-devel, то это просто
> очень плохой unmet.  А бывают unmet'ы практически безобидные. :)

Ну да, имеет место своеобразная транзитивность: если пакет A зависит
от пакета B, который получил unmet на пакет C, то пакет A тем самым
получил косвенный unmet на пакет C.

> > Кроме того, добро от "apt-cache unmet" ещё не даёт гарантии того, что
> > устанавливаемость не сломана.
> 
> Конечно.  А устанавливаемость не гарантирует работоспособности.

Конечно.  Но зато устанавливаемость, видимо, поддаётся автоматизированному
тестированию.

> Пересборка в большей степени дает проверку работоспособности.

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


-- 
ldv

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