Outdated advice regarding %global vs. %define #1449
Labels
No labels
announce
bootstrap
Closed As
accepted
Closed As
duplicate
Closed As
exceptionexpired
Closed As
fixed
Closed As
invalid
Closed As
nothingtodo
Closed As
permanentexception
Closed As
rejected
Closed As
temporaryexception
Closed As
wontfix
cmake
committee
draftneeded
hasdraft
meeting
meson
needinfo
Priority
In Committee
Priority
Needs Review
Priority
Waiting For Reporter
rust
writeup
No milestone
No project
No assignees
7 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
packaging/guidelines#1449
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
While its advice has been softened somewhat through the addition of some disclaimer language, the thrust of the section on how to define spec variables is still communicated by its title:
This is, in the words of RPM core developer Panu Matilainen, "bad advice that spread far and wide". Accompanied by a fuller explanation of how scoping (now) works for
%definevariables:We are strongly encouraged to stop telling people that they should be using
%globaleverywhere, or really anywhere, unless it's absolutely necessary. (Meaning, unless immediate expansion of the variable is required.) For most specfile needs, the lazy expansion provided by%defineis preferred.+1 to drop this rule
So the recommendation should be flipped, or what? From
to
?
Yes, pretty much.
Yes - that's how it really should've been all along. Even in the old days, %global was needed in one case where it no longer is (that
%{!?foo:%define foo bar}type construct), it didn't need this big hammer recommendation.How does this sound, for a new section? If we want I can open a PR and we can iterate on the wording there. (The two commands would be defined using a description list in asciidoc format.)
Defining variables (macros) in spec files
RPM supports two commands that can be used in
.specfiles to define new%-variables. (Called 'macros' in RPM terminology, since every%-expansion is a macro expansion. But macros can also be used for simple variable replacement.)%define::Expanded at time of use (lazy expansion).
A macro created with
%definecan use other macros in its definition,and all macros will be replaced with their current value
at the time the
%definemacro is expanded.This makes it very easy to use macros in loops,
or to change their definition in different parts of the spec file.
%global::Expanded at time of creation (immediate expansion).
A macro created with
%globalis expanded as soon as it is created,so that any
%-macros used in the definitionare substituted with their value
at the time the
%globalstatement is processed.Because a macro defined with
%globalno longer contains the
%-macros used in its definition,only their expanded values,
later modifications to those macros
will not affect the expansion of the global macro.
Packagers SHOULD use
%defineto create macros in spec files.Spec files MAY use
%globalinstead,if immediate expansion is needed (a rare occurrence).
I can't decide if it should still get into the whole topic of lazy expansion in global macros using
%%.And now I'm thinking the
[NOTE]should even be a[CAUTION].We discussed this at today's FPC meeting. We're generally in favor, so please send a pull request to implement it. Ideally we'd like to get @pmatilai's +1 on the exact wording in that PR.
I'll whip something up today (hopefully).
Hey @pmatilai, a question that came up while working on this:
Are there any differences in the handling of things like subshell calls, when using
%definevs.%global?There are a lot of
%globaluses in our packaging templates, so in addition to updating the guidelines I wanted to also update (at least some of) those. But then I ran into these macros from the TCL packaging guidelines:...And that got me wondering. If this macro definition:
%global tcl_version %(echo 'puts $tcl_version' | tclsh)is replaced with this macro definition:
%define tcl_version %(echo 'puts $tcl_version' | tclsh)...will every use of
%{tcl_version}be re-executing thatecho 'puts $tcl_version' | tclshshell command?If the answer is yes (though I doubt it is), we may want to continue recommending
%globalfor macros that invoke subshells or do other complex processing.First draft PR now opened as #1454.
Shell expansion isn't special in any way, so yes it's re-executed at each use of such macro. Sometimes it's what you need, sometimes not.
The real problem with the existing "use %global everywhere" is the "everywhere", and switching to "use %define elsewhere" just leads to different problems. One should use whichever is appropriate for a given situation. And to make that call, people will need to understand the difference.
Thanks, @pmatilai!, that's a big help! I'll have to make some adjustments to #1454.
RPM 6.1 will have
%define -gwith the same behavior as%globalwhich confuses this further. And RPM has documentation in https://rpm.org/docs/latest/man/rpm-macros.7#Macro_manipulation that pretty clearly explains the difference between%defineand%global. I wonder if we can just... remove this section from the Guidelines entirely since it's inaccurate, and our goal isn't to duplicate RPM documentation in the Guidelines.[master] Outdated advice regarding %global vs. %defineto Outdated advice regarding %global vs. %defineCareful - that's NOT the same as
%global.%define -g -eis. I'd say most people nowadays use%globalonly for the-eside-effect, or because that's what they were told to use. The need to declare a global macro inside a parametric function exists, but it's quite rare I would say.So if our updated documentation on the matter seems sufficiently clear on this, I tend to concur that just eliminating the distro-specific guidance might well be the best course of action. Packagers are far better off learning to use what they actually need than being instructed to use one thing or the other just because some ancient RPM version did something cooky with it.
+1 to removing this section from the Guidelines entirely
pmatilai, thanks for the point of information and also for the nice new RPM manpages.
I opened #1541 to propose removing the guideline.