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

[Kirill A. Shutemov]

2009/5/18 Victor B. Wagner <vitus на altlinux.org>:
>> > Э, как это нельзя? А grep ^%package filename.spec?
>>
>> Они (точнее секции %files) могут быть обёрнуты во всякие %if, т.о. этот grep ни
>> о чём не скажет. :(
>>
>
> Ну почему "ни о чем"? - это даст оценку сверху - такие-то и такие-то
> пакеты ПРИНЦИПИАЛЬНО МОГУТ БЫТЬ построены из этого исходника.
>
> Это уже дает существенную помощь при задаче распараллеливания.
> Причем безопасную. Любая ошибка будет on safe side - мы можем
> предположить что зависимость есть, а на самом деле её нет - она под %if,
> условие которого в данном случае не выполняется.
>
>
>> > С requires/provides действительно сложнее. Потому что 2/3 их ни разу в
>> > спеке явным образом не прописаны.
>> >
>> > Но вообще, насколько я помню, все Build-Requires выявляются на весьма
>> > раннем этапе сборки пакета. Выполнить prep-стадию ради того, чтобы
>> > собрать эту информацию, может оказаться оправданной затратой ресурсов.
>>
>> Разворачивание сборочной среды и установка Build-Requires, если я правильно
>> всё понял, должна помочь получить список подподпакетов. Но requires/provides
>> всё равно будут не доступны пока пакет не будет полностью собран. Так что это
>> тоже бессмысленно. :(
>
> Это опять же отнюдь не бессмыслено. Стопроцентной гарантии не дает, но
> существенные хинты дает.
>
> Если мы что-то Build-Requires, то
> скорее всего мы потом будем Requires либо его, либо что-то, собираемое
> из того же исходника. Случаи, когда пакет requires что-либо, что нафиг
> не нужно в процессе его сборки, не столь уж часты, и, главное, если он
> этого не Build-Requires, то смена версии этого в процессе параллельной
> пересборки вряд ли чего-нибудь сломает (а если сломает, то этого не
> выяснится и при последовательной пересборке - только при вдумчивом
> тестировании).

ИМХО, результаты предыдущей сборки должны лучшее приближение, чем
подобный анализ.