Re: RFC: Feature macros (aka USE flags)
Le jeudi 30 avril 2020 à 10:49 +0200, Petr Šabata a écrit :
On Tue, Apr 28, 2020 at 9:55 AM Nicolas Mailhot via devel
<devel(a)lists.fedoraproject.org> wrote:
> Le mardi 28 avril 2020 à 08:43 +0200, Petr Pisar a écrit :
> > On Mon, Apr 27, 2020 at 04:33:52PM +0200, Petr Šabata wrote:
> > > %_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
> > > }
>
> %{name} use in macro logic is unsafe because %{name} does not exist
> in
> the preamble before the Name: line, and the Name: line does not
> exist
> before you start declaring package headers.
>
> Once you’re in package
> header declaration mode rpm parser behaviour will prevent you from
> doing logic between headers blocks, so it all needs interleaving,
> which
> ends un not possible sanely in any semi-complex spec file.
You're correct but I can't think of any solution besides not using
the macros before you define Name, just like in your example below.
One positive result of all the ugliness in
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/83
(which is what happens, when people like you and me try to do
processing on %{name}, and rpm maintainers feel otherwise)
is a generic %new_package wrapper in redhat-rpm-config.
The PR, should it be merged, will get you several things:
1. a real %{source_name} variable in spec files (not just
%{source_name} emulation in dnf) that you can set and do things with
before entering package header land
2. a single entry point within each header, *after* %{source_name} and
%{name} are set, where you can do generic pre-header processing such as
the one you propose. And where you can choose between processing the
subpackage name or the SRPM name, because they are exposed in different
variables.
And it only requires, besides merging the PR, to replace Name: and
%package lines in a spec file with the corresponding %new_package line.
If the packager did not set %{source_name}, the first %new_package will
set it and own the SRPM (usual case).
rpm will sadly probably insist that the srpm header comes first, so you
can not use %{source_name} to shuffle package headers in interesting
ways. %new_package solves the following ordering problems only:
1. need to do things with the srpm name before entering dangerous
header land (your case)
2. need to know, for macros that create package headers, if they are
supposed to takeover the SRPM or not. The PR removes the need for
complex inter-macro syncronization, a macro can just use %new_package,
and that will check if source_name if free to use, matches the package
header name, or matches something else
I coded it for my own automation macro needs (in fonts and go packages)
but it also marches your use case nicely
Regards,
--
Nicolas Mailhot