У 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
FYI, так уже сейчас работает: http://git.altlinux.org/people/glebfm/packages/include-hack.git Что из этого более ужасно -- другой вопрос. :)
я попробую сделать так, как описывает глеб и посмотрю во что это выльется с точки зрения дальнейшего сопровождения. по результатам отпишусь. у меня таких пакетов может оказаться около 200-250.
(Ответ для Anton Farygin на комментарий #2) > я попробую сделать так, как описывает глеб и посмотрю во что это выльется с > точки зрения дальнейшего сопровождения. по результатам отпишусь. у меня > таких пакетов может оказаться около 200-250. Не, я всё же больше за твой вариант. В этот хаке большая часть спека не будет попадать в specs.git, а это было бы очень-очень обидно.
если развивать эту идею в более широком смысле, то, наверное, с помощью тэга можно было бы добавить возможность переопределения любых директив в .gear/rules Или, как вариант, использовать subst по данным тэга для содержимого .gear/rules
(Ответ для Gleb F-Malinovskiy на комментарий #3) > (Ответ для Anton Farygin на комментарий #2) > > я попробую сделать так, как описывает глеб и посмотрю во что это выльется с > > точки зрения дальнейшего сопровождения. по результатам отпишусь. у меня > > таких пакетов может оказаться около 200-250. > > Не, я всё же больше за твой вариант. В этот хаке большая часть спека не > будет попадать в specs.git, а это было бы очень-очень обидно. мне кажется, что могут сломаться ещё какие-то парсеры спеков. Врятли кто-то кроме rpm умеет Include. Хотя парсеры, конечно, в идеале должны работать через rpm.
(In reply to Anton Farygin from comment #5) > Хотя парсеры, конечно, в идеале должны работать через rpm. Нет, поскольку rpm во время работы парсера по определению исполняет произвольный код, это плата за безграничную гибкость спек-файлов.
если они не работают через rpm, то они не могут гарантировать никакую совместимость с ним. Но минусом естественно является исполнение произвольного кода.
