39573 2021-01-20 12:28:37 +0300 add specfile name to tag 2022-03-25 16:26:07 +0300 1 1 4 Development Sisyphus gear unstable x86_64 Linux NEW P5 normal --- 1 rider ldv glebfm iv ldv legion placeholder rider qa-sisyphus oldest_to_newest 195553 0 rider 2021-01-20 12:28:37 +0300 У 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 195555 1 glebfm 2021-01-20 13:31:44 +0300 FYI, так уже сейчас работает: http://git.altlinux.org/people/glebfm/packages/include-hack.git Что из этого более ужасно -- другой вопрос. :) 195557 2 rider 2021-01-20 13:43:36 +0300 я попробую сделать так, как описывает глеб и посмотрю во что это выльется с точки зрения дальнейшего сопровождения. по результатам отпишусь. у меня таких пакетов может оказаться около 200-250. 195559 3 glebfm 2021-01-20 13:50:19 +0300 (Ответ для Anton Farygin на комментарий #2) > я попробую сделать так, как описывает глеб и посмотрю во что это выльется с > точки зрения дальнейшего сопровождения. по результатам отпишусь. у меня > таких пакетов может оказаться около 200-250. Не, я всё же больше за твой вариант. В этот хаке большая часть спека не будет попадать в specs.git, а это было бы очень-очень обидно. 195560 4 rider 2021-01-20 13:52:19 +0300 если развивать эту идею в более широком смысле, то, наверное, с помощью тэга можно было бы добавить возможность переопределения любых директив в .gear/rules Или, как вариант, использовать subst по данным тэга для содержимого .gear/rules 195561 5 rider 2021-01-20 13:53:38 +0300 (Ответ для Gleb F-Malinovskiy на комментарий #3) > (Ответ для Anton Farygin на комментарий #2) > > я попробую сделать так, как описывает глеб и посмотрю во что это выльется с > > точки зрения дальнейшего сопровождения. по результатам отпишусь. у меня > > таких пакетов может оказаться около 200-250. > > Не, я всё же больше за твой вариант. В этот хаке большая часть спека не > будет попадать в specs.git, а это было бы очень-очень обидно. мне кажется, что могут сломаться ещё какие-то парсеры спеков. Врятли кто-то кроме rpm умеет Include. Хотя парсеры, конечно, в идеале должны работать через rpm. 195664 6 ldv 2021-01-22 18:01:25 +0300 (In reply to Anton Farygin from comment #5) > Хотя парсеры, конечно, в идеале должны работать через rpm. Нет, поскольку rpm во время работы парсера по определению исполняет произвольный код, это плата за безграничную гибкость спек-файлов. 195666 7 rider 2021-01-22 18:28:17 +0300 если они не работают через rpm, то они не могут гарантировать никакую совместимость с ним. Но минусом естественно является исполнение произвольного кода.