V Thu, Jun 06, 2024 at 08:36:25AM +0000, Zbigniew Jędrzejewski-Szmek napsal(a):
> 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")
>
Moreover, the scripts can be interpreted with a different shell than bash.
A shell where ${RPM_BUILD_ROOT:?} is invalid or has a different meaning.
That's actually a reason why to prefer manually typing shell variables in the
scripts: Shells know how to safely expand variables. rpm-build cannot know how
to escape the expanded value.
-- 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
