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

[Dmitry V. Levin]

On Mon, Jun 29, 2020 at 07:51:51PM +0300, Vladimir D. Seleznev wrote:
> On Mon, Jun 29, 2020 at 06:58:39PM +0300, Andrey Savchenko wrote:
> > On Mon, 29 Jun 2020 18:28:42 +0300 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, который вытягивает несколько гигабайт неизвестно чего.
> >  
> > Texlive вытягивает известно что. Есть более грациозные пути
> > упаковки texlive, соответствующие идеологии CTAN. Однако, наша
> > сборочница оказалась технически неспособна собрать такой пакет,
> > поскольку в ней неэффективно и немасштабируемо реализован install
> > check.
> 
> Я не согласен на счёт более грациозного пути упаковки. Разбивка на
> 10_000 подпакетов, сгенерированная роботом, не выглядит внушающим
> доверия. Текущая схема лучше, но тем не менее, подозреваю, что
> вытягивает лишнего. Хотя похоже ситуация стала лучше, по крайней мере я
> не вижу в зависимостях больше ruby.

Ситуация действительно стала немного лучше после того, как я оторвал
паразитные ruby-зависимости в texlive-texmf.


-- 
ldv