In a package review recently I was asked to put brackets around all macro usages. That is, writing
%{name}.desktop
rather than
%name.desktop
I personally think these superfluous brackets clutter the spec file and reduce the readability. So when they are not necessary I always omit them.
To me it somewhat strange that using brackets is more common than not doing so. The situation is quite analogous to shell scripts. In (ba)sh it is always ALLOWED to have brackets around variables, but only rarely REQUIRED. Exactly as it is for macros in spec files. But while you almost never see a shell script with brackets where they are not needed, it is quite common in spec files.
Should the packaging guidelines have a ruling on this? There isn't any as far as I can find. The closest I found was the choice between %{buildroot} and ${RPM_BUILD_ROOT}, and in that case the only requirement was consistency. Is consistency the only requirement in the choice between %{name} and %name too? Or is the use of %{name} with brackets actually required?
On 08/15/2011 12:02 PM, Göran Uddeborg wrote:
In a package review recently I was asked to put brackets around all macro usages. That is, writing %{name}.desktop rather than %name.desktop
imho, using brackets is near-universally safer, but I doubt we need to mandate it. If anyone's non-use of brackets ever does break anything, that's their responsibility to fix I suppose.
-- rex
Am 15.08.2011 19:12, schrieb Rex Dieter:
On 08/15/2011 12:02 PM, Göran Uddeborg wrote:
In a package review recently I was asked to put brackets around all macro usages. That is, writing %{name}.desktop rather than %name.desktop
imho, using brackets is near-universally safer, but I doubt we need to mandate it. If anyone's non-use of brackets ever does break anything, that's their responsibility to fix I suppose.
I'm the package reviewer who has critizized the missing brackets [1].
First, it is usual in almost all packages to use them. However, that's not reason enough to make them mandatory. Actually, I wrote about the readability. I'm using Gedit for writing and viewing the spec files, which uses gtksourceview for syntax highlighting. Gedit doesn't recognize any macros without brackets and doesn't highlight them. That's my experience regarding the readability, and I would strongly recommend to use the brackets. Either mandatory, or as a fully-or-nowhere choice, means, either always in a certain spec file, or nowhere.
Best Regards, Mario
Mario Blättermann:
I'm using Gedit for writing and viewing the spec files, which uses gtksourceview for syntax highlighting. Gedit doesn't recognize any macros without brackets and doesn't highlight them.
That must be a a bug. Regardless of Fedora's packaging guidelines, macros without brackets is legal purely syntactically.
https://bugzilla.gnome.org/show_bug.cgi?id=656671
(I'm using emacs, and its SPEC mode works correctly in this case.)
either always in a certain spec file, or nowhere.
I assume everyone would agree that consistency should be a requirement. I will make it consistent in "mindless.spec". I just wanted to wait for this discussion to see in which direction I would change it.
On 08/16/2011 12:23 PM, Göran Uddeborg wrote:
That must be a a bug. Regardless of Fedora's packaging guidelines, macros without brackets is legal purely syntactically.
How would it be able to identify macros without brackets?
Say you have:
%namev%version
Is the macro %namev? %name? %na?
It is sloppy form. It is impossible to parse. Just because rpm will accept it doesn't mean you should use it.
~tom
== Fedora Project
On Tue, 16 Aug 2011 13:18:05 -0400, TC (Tom) wrote:
On 08/16/2011 12:23 PM, Göran Uddeborg wrote:
That must be a a bug. Regardless of Fedora's packaging guidelines, macros without brackets is legal purely syntactically.
How would it be able to identify macros without brackets?
Say you have:
%namev%version
Is the macro %namev? %name? %na?
It is sloppy form. It is impossible to parse. Just because rpm will accept it doesn't mean you should use it.
RPM may accept it, but it cannot always parse it correctly either:
echo "a=b" > %nameconfig.cfg
won't do the right thing even with %name being defined by default. For
echo "a=b" > %{name}config.cfg
to break similary, %name would need to be undefined.
Tom Callaway:
%namev%version
Is the macro %namev? %name? %na?
Michael Schwendt:
RPM may accept it, but it cannot always parse it correctly either:
echo "a=b" > %nameconfig.cfg
won't do the right thing even with %name being defined by default.
Are you joking? Or am I missing something? Of course, it means %namev and %nameconfig respectively.
Reusing the analogy with the shell, if you in a shell script see the code
echo $PATHTYPE
would you be unsure if that meant the value of the variable PATH followed by the string "TYPE", or if it meant the value of the variable PATHTYPE? I don't think you would.
Save for Fortran, in all programming languages I can recall the parser takes the longest sequence of characters that is a valid token to be the next token from the input.
I don't understand what you find so different in the spec file case.
Tom Callaway:
It is sloppy form.
Oh, come on! I understand you prefer the style with brackets. And your opinion certainly has much more weight than mine in Fedora.
I do have a different preference. Not because I am sloppy and wish to type a few characters less. Because I do find it easier to read without brackets that don't carry any information.
I find that accusation unfair.
On 08/18/2011 12:57 PM, Göran Uddeborg wrote:
Tom Callaway:
%namev%version
Is the macro %namev? %name? %na?
Michael Schwendt:
RPM may accept it, but it cannot always parse it correctly either:
echo "a=b"> %nameconfig.cfg
won't do the right thing even with %name being defined by default.
Are you joking? Or am I missing something? Of course, it means %namev and %nameconfig respectively.
The point is that many specs need something like %{name}v%{version} or %{name}config but NOT %{namev}%{version} or %{nameconfig}. Without brackets, they would be parsed as the latter which would not be the intended result (don't forget many packagers are not programmers by nature).
I would support explicitly making usage of brackets on macros a SHOULD item for packaging guidelines/reviews.
On 18 August 2011 21:49, Christopher Aillon caillon@redhat.com wrote:
The point is that many specs need something like %{name}v%{version} or %{name}config but NOT %{namev}%{version} or %{nameconfig}. Without brackets, they would be parsed as the latter which would not be the intended result (don't forget many packagers are not programmers by nature).
I would support explicitly making usage of brackets on macros a SHOULD item for packaging guidelines/reviews.
Fully agree, fwiw.
IMO, the guiding principle should be the answer to the question "what style would most enable another packager to pick up the spec file and fix problems with it". Knowing the intimate low-level workings of the spec file parser should not be a requirement for maintaining any package in Fedora when there are available syntaxes which negate the need for that intimate low-level knowledge.
On Thu, 2011-08-18 at 21:57 +0200, Göran Uddeborg wrote:
Tom Callaway:
%namev%version
Is the macro %namev? %name? %na?
Michael Schwendt:
RPM may accept it, but it cannot always parse it correctly either:
echo "a=b" > %nameconfig.cfg
won't do the right thing even with %name being defined by default.
Are you joking? Or am I missing something? Of course, it means %namev and %nameconfig respectively.
Reusing the analogy with the shell, if you in a shell script see the code
echo $PATHTYPE
would you be unsure if that meant the value of the variable PATH followed by the string "TYPE", or if it meant the value of the variable PATHTYPE? I don't think you would.
Save for Fortran, in all programming languages I can recall the parser takes the longest sequence of characters that is a valid token to be the next token from the input.
I don't understand what you find so different in the spec file case.
spec. files are _not_ a programming language. You can't do loops, for example. Even reassigning variables is ... unwise. As a related point, a significant number of people who want to look at them are not programmers. In general I'd expect to see %{foo} for normal variables and %foo for "special" variables, like %add_to_maven_depmap or %py_byte_compile etc.
Tom Callaway:
It is sloppy form.
Oh, come on! I understand you prefer the style with brackets. And your opinion certainly has much more weight than mine in Fedora.
Indeed ... most of the reason for FPC and the guidelines is because "good" consistency is better than "perfect" uniqueness. There are over 10,000 source packages in F15 GA, it makes a big difference.
On Thu, 18 Aug 2011 21:57:43 +0200, GU (Göran) wrote:
Tom Callaway:
%namev%version
Is the macro %namev? %name? %na?
Michael Schwendt:
RPM may accept it, but it cannot always parse it correctly either:
echo "a=b" > %nameconfig.cfg
won't do the right thing even with %name being defined by default.
Are you joking? Or am I missing something? Of course, it means %namev and %nameconfig respectively.
What about these?
%define name emacs ln -s %name %name23.2 ln -s %name %name-23.2 ln -s %name %name_23.2 ln -s %name %name_%version ln -s %name %name23 mv %name.man %name.2
Do you parse them all without testing? (not even programming language knowledge is helpful in all cases)
Unless we can teach editors (the most common ones used to edit RPM spec files) to do the variable highlighting correctly, explicit brackets are the way to go. If a variable name is surrounded by whitespace, missing brackets are okay.
On 08/19/2011 11:00 AM, Michael Schwendt wrote:
Unless we can teach editors (the most common ones used to edit RPM spec files) to do the variable highlighting correctly, explicit brackets are the way to go. If a variable name is surrounded by whitespace, missing brackets are okay.
Or, you can just build a habit around always using brackets and avoid spending an hour trying to figure out why a macro is evaluating incorrectly or why a file name is being written out wrong. :)
~tom
== Fedora Project
Michael Schwendt:
Do you parse them all without testing?
From your question I was kind of expecting some surprising exception.
But when I tested they all behaved the way I would have thought.
But it doesn't matter. I understand I'm not convincing anyone, and I'll change my package to follow this rule.
One more detail before I go away. Spec files do contain small scripts (%build, %post, etc.) These scripts can use both spec file macros and shell variables. The exchangable %{buildroot} and ${RPM_BUILD_ROOT} for example. Does the rule to to always use brackets apply to both, or only to the spec macros?
On 08/19/2011 11:45 PM, Göran Uddeborg wrote:
Michael Schwendt:
Do you parse them all without testing?
I sense a misunderstanding.
People seem to presume rpm.specs to be written in a "well defined programming language" using a lexical scanner and parser underneath.
This does not apply, the "rpm.spec language" is a "macro language", similar to regexes and m4, using macro sets underneath, similar to autoconf or sendmail, with all kind of ambiguities and "historic heritage and historic heuristics" underneath.
I.e. rpm doesn't actually "parse" spec files in the sense compilers/interpreters would parse/interpret a well "defined language", it expands macros and passes the results to other parties.
From your question I was kind of expecting some surprising exception.
But when I tested they all behaved the way I would have thought.
But it doesn't matter. I understand I'm not convincing anyone, and I'll change my package to follow this rule.
One more detail before I go away. Spec files do contain small scripts (%build, %post, etc.) These scripts can use both spec file macros and shell variables. The exchangable %{buildroot} and ${RPM_BUILD_ROOT} for example. Does the rule to to always use brackets apply to both, or only to the spec macros?
They are supposed to be complete independent.
Actually, rpmbuild first expands the macros inside of spec's scriptlet and then hands the results over to the shell.
I.e. rpm itself is supposed not even to touch to let it pass through as "arbitrary text".
Ralf
On Sat, 20 Aug 2011 07:16:25 +0200, RC (Ralf) wrote:
On 08/19/2011 11:45 PM, Göran Uddeborg wrote:
Michael Schwendt:
Do you parse them all without testing?
I sense a misunderstanding.
People seem to presume rpm.specs to be written in a "well defined programming language" using a lexical scanner and parser underneath.
To clarify my use of the term "parse" above, what I meant is the human parser. Whether the reader of the spec file is able to _recognise_ a macro easily/immediately. Especially in situations where they are surrounded by non-space characters. Brackets not only aid the human reader but also the machine that substitutes macros with their values. Or the editor that applies syntax highlighting.
This does not apply, the "rpm.spec language" is a "macro language", similar to regexes and m4, using macro sets underneath, similar to autoconf or sendmail, with all kind of ambiguities and "historic heritage and historic heuristics" underneath.
I.e. rpm doesn't actually "parse" spec files in the sense compilers/interpreters would parse/interpret a well "defined language", it expands macros and passes the results to other parties.
What constitutes a macro? What is the grammar? If we restrict ourselves to using only a subset of the possible expressions that build macro names, we can avoid errors and increase readability.
Since you talk about "ambiguities", those commonly lead to bugs with poorly named variables in programming languages, too, not just RPM spec files.
In a sufficiently large spec file with more than the default set of macros, it isn't obvious whether %name2 is expected to be %{name}2 instead and what lib%name_* is meant to match. rpmbuild wouldn't complain. Unexpanded macros have lead to errors in packages before. Mixed macro usage like %version and %ver has been seen before, too, a pitfall when replacing %ver with something else and either messing up %version or forgetting a single %{ver}.
Btw, do you agree with making explicit brackets a SHOULD?
On Mon, Aug 15, 2011 at 12:12:24PM -0500, Rex Dieter wrote:
On 08/15/2011 12:02 PM, Göran Uddeborg wrote:
In a package review recently I was asked to put brackets around all macro usages. That is, writing %{name}.desktop rather than %name.desktop
imho, using brackets is near-universally safer, but I doubt we need to mandate it. If anyone's non-use of brackets ever does break anything, that's their responsibility to fix I suppose.
To expand on this, just like shell, you can get into trouble if you write something like (contrived example): Source0: %namer%version.tar.gz
But earlier in the spec file (or from one of rpmn's system-wide configs):
%define namer foo
One counter example is when the macro is itself a little script that needs to take arguments. In that case rpmbuild will hand the arguments to the macro when you do not use the curly braces but won't when you do (unless you include the arguments inside of the curly braces). See %py_byte_compile for an example of this.
-Toshio
packaging@lists.fedoraproject.org
-
Christopher Aillon -
Göran Uddeborg -
James Antill -
Jonathan Underwood -
Mario Blättermann -
Michael Schwendt -
Ralf Corsepius -
Rex Dieter -
Tom Callaway -
Toshio Kuratomi