On Thu, Apr 30, 2020 at 10:43:51AM +0200, Petr Šabata wrote:
On Tue, Apr 28, 2020 at 8:55 AM Petr Pisar ppisar@redhat.com wrote:
On Mon, Apr 27, 2020 at 04:33:52PM +0200, Petr Šabata wrote:
On Mon, Apr 27, 2020 at 4:04 PM Petr Pisar ppisar@redhat.com wrote:
(2) Is it possible to override them on a per-package basis?
E.g. I have ncurses in global.yaml:
- name: ncurses description: Add support for ncurses. enabled: trueand I have plenty of packages that use the ncurses feature in my module. What should I write to my modulemd so that "ncurses" feature for "pcre" package is disabled, but all the other packages have it enabled? Or is it a completelly illed request to have the same feature enabled at one package and disabled on another one?
It is and that's actually how the local is implemented. It extends the basic definitions with %{name} checks like this:
%_use_ncurses %{lua: if rpm.expand("%{name}") == "yourpackage1" or rpm.expand("%{name}") == "yourpackage2" then print(rpm.expand("%{bcond_with foo}%{with foo}")) else print(rpm.expand("%{bcond_without foo}%{with foo}")) end }
I know it's not very user friendly. Maybe there's a better way that doesn't blow up on recursive macro definition.
Do I understand it correctly that modules should reimplement the %_use_ncurses macro? That's really clumsy and I'd like to avoid it. Not speaking about the issues with recursion you are aware and I was hoping you found a solution. Modules would have to simply redefine the macro covering all packages built in the module.
Yes, it is clumsy and you're correct here.
MBS also just extends the macro definitions so I'm not sure how to work around the recursion problem even if we introduced a new modulemd section just for this (which wouldn't feel right either). Would you have any suggestions?
Unfortunately I have no suggestion. I agree that the new modulemd section would be an overkill.
Actually if the generation of the macros was postponed to a spec file, there would not have to exist any local.yaml file. That way the spec file would be be self-contained. I agree with others that separating the local overrides into local.yaml maintained in a different package is not handy and slows the packager's work flow.
But it also defeats the idea of these being set by the system, leaving package repos untouched.
You are right. I forgot this use case.
Probably because local.yaml is a misnomer. local.yaml is a distribution-wide configation like global.yaml. It's only per-package configuration. In Gentoo, "local" use flags are indeed defined next to the ebuild. But in Fedora their definition would be separated from the packages. local.yaml is more alike to a Gentoo profile.
Technically local.yaml (it's actually a set of locale.%{name}.yaml files) could be merged into the global.yaml file. But the syntax would be horrible because there would be a tension whether to collate them by a feature and then by a package name, or vice versa. Not speaking about an inflation by the descriptions. I miss the Gentoo brevity:
* ncurses pcre -ncurses
-- Petr