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@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?
>
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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
