[devel] ресурсоёмкое тестирование пакетов

[Kirill A. Shutemov]

2009/5/18 Victor B. Wagner <vitus на altlinux.org>:
> On 2009.05.15 at 23:26:30 +0400, Alexey Tourbin wrote:
>
>> Потому что такова семантика сборки заданий: они обладают семантикой
>> транзакции.  Если задание собрано успешно, то оно переводит репозитарий
>> в новое состояние, и сборка следующего задания начинается уже на новом
>> репозитарии.  Нельзя начинать собирать несколько заданий на старом
>> репозитарии и потом "сводить" несколько результатов сборки в один новый
>> репозитарий.  Это может закончиться очень плохо.
>
> 1. Будет ли это "очень плохо" своевременно диагностировано?
> 2. С насколько высокой вероятностью это "очень плохо" может случиться?
>
> А то может быть ждать десять раз по два часа плюс один раз - семнадцать
> (когда "очень плохо - случилось, и пришлось откатываться и строить все
> последовательно) будет несколько эффективнее, чем 11 раз по 15 часов?
>
> Вообще, с очевидность МОЖНО собирать несколько заданий на старом
> репозитарии и потом их сводить, при условии что эти задания от
> результатов друг друга абсолютно независимы.
>
> Понятно, что есть такие пакеты, от которых зависит практически все -
> filesystem, toolchain, базовые библиотеки. С ними почти ничего не
> запараллелишь. Но что мешает запараллелить, например, сборку
> какой-нибудь гномовской фигни со сборкой аналогичной kde-шной фигни?
> Или там сборку двух mail transfer agent-ов которые с точки зрения
> некоторых дистрибутивов принципиально не могут использоваться
> одновременно?

В общем случае нельзя понять как задания повлияют друг на друга до того как
они будут собраны, поскольку нельзя заранее знать какие бинарные пакеты
будут собраны из данного исходного и какие requires/provides будут у этих
пакетов. Однако, можно стороить пердположения на основе предыдущих сборок
пакетов входящих в задание. Мне видиться, что эти предположения могут быть
достаточно релевантны.