On Thu, Jun 06, 2024 at 09:53:48AM +0300, Panu Matilainen wrote:
> 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.
I don't think we could ever change %buildroot to be ${RPM_BUILD_ROOT:?},
because the variable may be used in context where shell variable expansion
is not supported… (E.g. a trivial "find '%{buildroot}' -name '*.a' -delete")
Zbyszek
--
_______________________________________________
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
