[Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)

[Panu Matilainen]

> Therefore, the change makes them all latent build failures, as soon as the packager attempts using %{name} in sources, patches, or sourcedir (as evidenced by the breakage when dejavu-fonts needed its first patch in years).

Once more: this has been in Fedora and other distros for almost a year. World hasn't ended, I hadn't heard a single mention of it until now. Those packages have been built a lot in the meanwhile.

Avoiding use of macros before they're declared is all that is needed, it's not as if you can't write source/patch names literally if that's what the pattern in these packages requires. Use of %{name} in throughout specs comes from wanting to avoid repetition, but much of the time it's not really the right thing to use to begin with: the *package* name could change, upstream name doesn't. You don't have to use *%{name}* to avoid repetition. Declare your own naming macro (`%define myname foo` or whatever) at the top of the spec and use it for the rest of the spec, including in the actual Name: tag. Which frees you from the ordering constraints that force you to put Name later than usual in the spec.

The only real victim here is use of spec-defined macros in %_sourcedir (and other similar paths), which always was a "kinda works" thing at best. Of course by accident is not how you want to introduce compatibility breaks, but sometimes stuff happens nevertheless. If this had been brought up last summer during 4.15 development stages I would've been more inclined to revert at least temporarily, but evidence suggests that this isn't a common setup, and for a reason. I'd really recommend switching to the dist-git style per-package setup based around $PWD that most of the world has settled upon by now, as that's where rpm is headed too once somebody figures out how to handle the transition.

One off-line realization from yesterday evening was that the former behavior of re-expanding source/patch paths on use throughout the build means that it's possible to change them as well, so you could use different material for building than what ends up being packaged in src.rpm. That, along with the other escape etc issues that come with multiple expansion (eliminating which has been a bit of a theme in 4.16, although this happened much earlier), and simplicity of "declare before use" rule all seem supportive of what we ended up.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-611350130
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20200408/ea530df3/attachment.html>