Re: RPM_* env variables vs macros

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

 



On 6/5/24 18:22, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Jun 04, 2024 at 09:31:47AM +0200, Vít Ondruch wrote:

Dne 04. 06. 24 v 9:27 Vít Ondruch napsal(a):

Dne 04. 06. 24 v 8:11 Panu Matilainen napsal(a):
On 6/3/24 17:18, Eike Rathke wrote:
Hi Panu,

On Monday, 2024-06-03 15:55:09 +0300, Panu Matilainen wrote:

or better yet, ${RPM_BUILD_ROOT}.

Why better?

In general, the RPM_* environment variables available to build
scriptlets are what should be used instead of macros. Because,
macros are processed while parsing the spec, which is different from
actually *building* it. For one, using the environment improves srpm
reproducibility because the local gunk like number of CPUs, the
concrete path of %buildroot etc are only visible the scriptlets
where actually used.

It's a subtle thing, took me 10+ years with rpm to grok the
recommendation I'd seen long, long, long ago.


I wish this nugget was captured somewhere on more prominent place.
Because what you say does not really correspond with what we have in
guidelines:

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_using_buildroot_and_optflags_vs_rpm_build_root_and_rpm_opt_flags


And I have not checked the RPM documentation


There is this section:

https://rpm-software-management.github.io/rpm/manual/spec.html#build-scriptlets

also recommending RPM_ macros for scriptlets:

I acknowledge what Panu wrote, but I think there are also countervailing reasons
to prefer the macro:
- it is shorter and generally more consistent with the rest of the spec file,
   which will have many many macros and only occasionally a shell variable,
   so the macro is more aesthetic.
- but the big thing is that the macro is safe wrt. typos, while the variable
   not so much. It's just too easy to make a stupid typo in the variable name
   and do bad things™ in a local build.

   ${RPM_BUILD_ROOT:?} would be a better way to spell the variable reference,
   but that's too long expect people to use it.

Yeah the thing is those macros can and will never go away because everybody instinctively prefers them for consistency within the spec, shorter to type and all.


So maybe we should have a macro that would expand to the env var:
   %global BUILDROOT ${RPM_BUILD_ROOT:?}
and recommend that people use that instead?

That'd be a third variant of the same thing, probably causing even more confusion, and specs using that would be incompatible with everything else. Let's not.

Making the macros expand to the corresponding environment variables is a is a sound strategy though, and what we're doing with %_smp_mflags already:

%_smp_mflags -j${RPM_BUILD_NCPUS}

It can cause some breakage though so care needs to be taken. And just now, we've already rocked the boat more than is entirely healthy for a single release, so further experiments in this area will have to wait for some other time.

	- Panu -

	- Panu -
--
_______________________________________________
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
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[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