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

[Kirill A. Shutemov]

2009/5/18 Victor B. Wagner <vitus на altlinux.org>:
> On 2009.05.18 at 13:43:29 +0300, Kirill A. Shutemov wrote:
>
>>
>> В общем случае нельзя понять как задания повлияют друг на друга до того как
>> они будут собраны, поскольку нельзя заранее знать какие бинарные пакеты
>> будут собраны из данного исходного и какие requires/provides будут у этих
>
> Э, как это нельзя? А grep ^%package filename.spec?

Они (точнее секции %files) могут быть обёрнуты во всякие %if, т.о. этот grep ни
о чём не скажет. :(

> С requires/provides действительно сложнее. Потому что 2/3 их ни разу в
> спеке явным образом не прописаны.
>
> Но вообще, насколько я помню, все Build-Requires выявляются на весьма
> раннем этапе сборки пакета. Выполнить prep-стадию ради того, чтобы
> собрать эту информацию, может оказаться оправданной затратой ресурсов.

Разворачивание сборочной среды и установка Build-Requires, если я правильно
всё понял, должна помочь получить список подподпакетов. Но requires/provides
всё равно будут не доступны пока пакет не будет полностью собран. Так что это
тоже бессмысленно. :(

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

Согласен.