On Tue, Apr 28, 2020 at 8:55 AM Petr Pisar <ppisar(a)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(a)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: true
> >
> > and 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