On Tue, Apr 28, 2020 at 8:55 AM Petr Pisar <ppisar@xxxxxxxxxx> 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@xxxxxxxxxx> 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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
