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

[Victor B. Wagner]

> > Э, как это нельзя? А 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, то смена версии этого в процессе параллельной
пересборки вряд ли чего-нибудь сломает (а если сломает, то этого не
выяснится и при последовательной пересборке - только при вдумчивом
тестировании).