On Sun, 24 Dec 2017, Dmitry V. Levin wrote:

>> Да, сделаю. Надо только написать в описании пакета, что он существует
>> только для install-test в сборочнице и его не нужно ставить в реальную
>> систему. Мне не слишком нравится, что в Сизифе будет такие пакеты, но
>
> Мне кажется, что это, наоборот, очень перспективная тема.
>
> Для того, чтобы пакеты *-install-test не были установлены случайно, можно
> - индексировать их отдельно, по аналогии с *-debuginfo;
> - подключать этот индекс только при тестировании установки пакетов
>  *-install-test;
> - завести фиксированный формат %description таких пакетов,
>  и проверять их на стадии sisyphus_check.

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

1) check_*_pkg

2)
check_NAME0_pkg_with_NAME1
check_NAME0_pkg_with_NAME1_NAME2

или check_NAME0_NAME1_NAME2_pkgs

Второе -- на случаи, если захочется тестировать каждый раз, например, при 
обновлении NAME1, NAME2 (поставить зависимость на их EVR).

Разделитель другой (_), чтобы легче было читать NAME* обычных пакетов 
(вычленять), учитывая, что обычный разделитель -- это - (rpm-build так 
оформляет подпакеты).

Чтобы не спутатьс пакетами, просто пакующими тесты, я решил, что нужно 
использовать на слово test в названии, а check. (Чтобы ни люди не 
спутали, ни автоматика, которая их будет откладывать в отдельный 
подрепозиторий.) К тому же это больше похоже на команду "Check smth!", что 
отражает суть: поставить этот пакет == проверить что-то (это действие 
произойдёт в системе).

Обрамлять название пакета с двух сторон (check_*_pkg) мне захотелось, 
чтобы с большей вероятностью избежать совпадений с обычными пакетами.

Единственное, что мне в этой схеме не очень нравится -- это то, что они 
все будут иметь одинаковое начало, а это мешает сортировке, работе со 
спсиком (как со "словарём") пакетов отдельного подрепозитория...

Есть ещё мысль: следует иметь в виду разные возможности:

1) более сильные install-time проверки check_NAME0_NAME1_NAME2_pkgs с
    зависимостями на EVR всех пакетов. Будут вызывать unmet-ы при,
    требовать прохождения при сборке новых релизов сразу же.

2) более слабые (информационные) аналоги check_NAME0_NAME1_NAME2_pkgs с 
build-time проверками; они в BuildPreReq ставят проверяемые пакеты, и в 
%build делают их тесты. Тогда о нерохождении мы будем информироваться 
просто раз в сутки в рамках FTBFS от beehive. Схему именования я ещё не 
придумал.

-- 
Best regards,
Ivan