Bug 39573

Summary: add specfile name to tag
Product: Sisyphus Reporter: Anton Farygin <rider>
Component: gearAssignee: Dmitry V. Levin <ldv>
Status: NEW --- QA Contact: qa-sisyphus
Severity: normal    
Priority: P5 CC: glebfm, iv, ldv, legion, placeholder, rider
Version: unstable   
Hardware: x86_64   
OS: Linux   

Description Anton Farygin 2021-01-20 12:28:37 MSK
У ocaml считается обычным явлением собирать из одного дерева исходников разные пакеты. Например - dune - /usr/bin/dune это один пакет, с одним набором сборочных зависимостей, dune-configurator - другой пакет, с другим набором сборочных завимостей и т.д.
На данный момент это 6 пакетов в случае dune, собираемые из одного дерева исходников.

dune                               2.8.1       Fast, portable, and opinionated build system
dune-action-plugin                 --          [experimental] API for writing dynamic Dune actions
dune-build-info                    --          Embed build informations inside executable
dune-configurator                  --          Helper library for gathering system configuration
dune-deps                          --          Show dependency graph of a multi-component dune project
dune-glob                          --          Glob string matching language supported by dune
dune-private-libs                  --          Private libraries of Dune

Всё бы ничего, но подпакеты зависят на основной пакет dune (/usr/bin/dune) и, одновременно, на другие библиотеки ocaml. собираемые с использованием как /usr/bin/dune, так и (например) dune-configurator.

Сейчас в gear не предусмотрено штатного механизма для того, что бы держать в одном дереве spec-файлы для разных пакетов. А в данном случае было бы удобно управлять specfile для сборке не из .gear/rules, а, например, из тэга (по аналогии с механизмом specsubst)

В этом случае будут разные src.rpm с дублями исходников и разные бинарные пакеты, а самое главное - всю транзакцию можно будет сделать в одном задании и из одного исходников, не раскладывая spec файлы по веткам.

Предлагаю обсудить возможные реализации такого функционала, как управлением тэгом specfile из .gear/rules с помощью тэга gear, добавив в его описание ключевое слово, например:
X-gear-rules-specfile: .gear/dune-configurator.spec
Comment 1 Gleb F-Malinovskiy 2021-01-20 13:31:44 MSK
FYI, так уже сейчас работает:
http://git.altlinux.org/people/glebfm/packages/include-hack.git

Что из этого более ужасно -- другой вопрос. :)
Comment 2 Anton Farygin 2021-01-20 13:43:36 MSK
я попробую сделать так, как описывает глеб и посмотрю во что это выльется с точки зрения дальнейшего сопровождения. по результатам отпишусь. у меня таких пакетов может оказаться около 200-250.
Comment 3 Gleb F-Malinovskiy 2021-01-20 13:50:19 MSK
(Ответ для Anton Farygin на комментарий #2)
> я попробую сделать так, как описывает глеб и посмотрю во что это выльется с
> точки зрения дальнейшего сопровождения. по результатам отпишусь. у меня
> таких пакетов может оказаться около 200-250.

Не, я всё же больше за твой вариант.  В этот хаке большая часть спека не будет попадать в specs.git, а это было бы очень-очень обидно.
Comment 4 Anton Farygin 2021-01-20 13:52:19 MSK
если развивать эту идею в более широком смысле, то, наверное, с помощью тэга можно было бы добавить возможность переопределения любых директив в .gear/rules

Или, как вариант, использовать subst по данным тэга для содержимого .gear/rules
Comment 5 Anton Farygin 2021-01-20 13:53:38 MSK
(Ответ для Gleb F-Malinovskiy на комментарий #3)
> (Ответ для Anton Farygin на комментарий #2)
> > я попробую сделать так, как описывает глеб и посмотрю во что это выльется с
> > точки зрения дальнейшего сопровождения. по результатам отпишусь. у меня
> > таких пакетов может оказаться около 200-250.
> 
> Не, я всё же больше за твой вариант.  В этот хаке большая часть спека не
> будет попадать в specs.git, а это было бы очень-очень обидно.

мне кажется, что могут сломаться ещё какие-то парсеры спеков. Врятли кто-то кроме rpm умеет Include.

Хотя парсеры, конечно, в идеале должны работать через rpm.
Comment 6 Dmitry V. Levin 2021-01-22 18:01:25 MSK
(In reply to Anton Farygin from comment #5)
> Хотя парсеры, конечно, в идеале должны работать через rpm.

Нет, поскольку rpm во время работы парсера по определению исполняет произвольный код, это плата за безграничную гибкость спек-файлов.
Comment 7 Anton Farygin 2021-01-22 18:28:17 MSK
если они не работают через rpm, то они не могут гарантировать никакую совместимость с ним.

Но минусом естественно является исполнение произвольного кода.