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?
Since you use Lua (because RPM conditions are not allowed there), wouldn't be better to export the mapping from a package name to a feature as a Lua associative array? Modules would then just added/rewrote a tuple there and than call a Lua function to regenerate the %_use macros?
Yes, that would be nicer. I'll look into that.
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.
P