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.
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?
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.
-- 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
