Re: RFC: Feature macros (aka USE flags)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/27/20 5:33 PM, Petr Šabata wrote:
On Mon, Apr 27, 2020 at 4:04 PM Petr Pisar <ppisar@xxxxxxxxxx> wrote:

On Mon, Apr 27, 2020 at 01:19:29PM +0200, Petr Šabata wrote:
Details in the gist:
https://gist.github.com/contyk/0aaaaf0585c57976ca18a293b3566408

I'm very interested in overriding the global settings:

(1) Is it possible to override them from a modulemd when building a module?

I guess the asnswer is define %_with_ and %_without_ macros in
a buildopts/rpms/macros section of the module. Could elaborate more
the "Compatibility with RPM's --with & --without options" section?

Yes, you can, and that's exactly how you would do that.

Currently the macros as defined with bconds, in the basic form for
enabled by default:

%_with_foo %{bcond_without foo}%{with foo}

Please note hat the RPM options and the macros have three states (true, false,
undefined) and %_with_foo 0 does not turn %bcond_without foo into false.
I don't ask about preserving a compatibility with this silly semantics, but
some clarification will be needed if this proposal becomes approved.

It might not work if with/without is set with these macros directly as
it is written right now. I'll have to test that.

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

Not entirely sure if we're talking about the same "local" here but I spotted this in the use-macros.spec:

# %%global local

for source in string.gmatch(rpm.expand("%{?local}"), "[%w_-]+")

Please avoid taking over such broadly generic names as "local" in the global macro namespace, rpm might well want to use %local as a macro primitive (opposite of %global) one day.

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
}

Danger Will Robinson.

Such checks will on %{name} will only work after the Name: tag in the spec, which is not obvious from the outset, and there's a large set of packages in Fedora that only declare the name towards the end of the spec preamble.

	- Panu -

I know it's not very user friendly. Maybe there's a better way that
doesn't blow up on recursive macro definition.

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

_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux