[devel] как правильно использовать %check?

[Ivan Zakharyaschev]

On Mon, 29 Jun 2020, Dmitry V. Levin wrote:

> On Mon, Jun 29, 2020 at 05:52:24PM +0300, Vladimir D. Seleznev wrote:
> > On Mon, Jun 29, 2020 at 05:38:13AM +0300, Денис Смирнов wrote:
> > > On Fri, Jun 26, 2020 at 07:06:16PM +0300, Vitaly Lipatov wrote:
> > > 
> > > >> А зачем обязательно в PDF? Почему недостаточно HTML? Его и проверить
> > > >> проще, что там получилось...
> > > > Ещё у нас есть механизм, использующий упаковку тестов в подпакет 
> > > > checkinstall
> > > > И некоторые даже о нём знают и пользуются:
> > > > https://lists.altlinux.org/pipermail/devel/2019-December/209294.html
> > > 
> > > То есть идея в создании виртуального подпакета %name-checkinstall, у которого в %pre или %post скрипте выполняется тест?
> > 
> > Мне кажется, это слишком сложно для данного случая. Лучше ограничиться
> > скриптом в секции %check.
> 
> С другой стороны, существуют токсичные пакеты, попадание которых
> в сборочную среду следует избегать.  К таким пакетам относится
> rpm-build-ruby, который имеет свойство гулять по файловой системе,
> и texlive, который вытягивает несколько гигабайт неизвестно чего.

Ещё не бОльшая, а меньшая сложность оформления запуска тестов как 
*-checkinstall-пакета (зависящего от пакета *-tests) может достигаться 
благодаря автопоиску зависимостей в пакете *-tests -- вместо того, чтобы 
долго и мучительно их вручную подбирать, записывать, потом поддерживать в 
актуальном состоянии.

Думаю, со многими python-* пакетами это сильно упростило бы спек-файлы. 
Правда, на этом пути есть небольшая проблема: в питоновских тестах пишут 
import-ы часто на более глубоком уровне вложенности, чем учитывает 
автопоиск зависимостей (но это настраиваемый параметр в принципе -- но при 
большой глбуине возникнут проблемы исключающих альтернатив):

try:
	import XXX

Ещё одно преимущество избавления от BuildRequires ради тестов -- разрыв 
циклов по сборочным зависимостям при пересборке множества пакетов 
(например, с новым ABI библиотеки -- тогда старые сборки уже не работают 
в промежутке между старым и новым состоянием) или при бутстрапе новой 
архитектуры: можно сначала кучу пакетов собрать, а когда вся куча будет 
готова -- запустить их взаимозависимые тесты.

-- 
Best regards,
Ivan