There are two forms of using macros in spec files - %{macro} and %macro. RPM supports second form since 4.0, IIRC.
In one of my packaged I used %_bindir macro and was told by reviewer to change it to %{_bindir}. OTOH, %configure is also a macro, but it is widely used without curly brackets.
What's the point of using %{macro} form for some, but not all macros?
Hello All!
2013/4/19 Alexey I. Froloff raorn@raorn.name:
What's the point of using %{macro} form for some, but not all macros?
That's mostly a cosmetic issue but sometimes this *could* cause a real problem.
Let's say someone defines a macro "_bindirmacro", and actually starts using it in a spec-files. Then there will be an ambiguity during substituting %_bindirmacro - is this %{_bindir}macro or %{_bindirmacro}? Adding brackets will resolve this.
I saw this issue once but didn't remember exact details.
-- With best regards, Peter Lemenkov.
On Fri, Apr 19, 2013 at 01:00:31PM +0400, Peter Lemenkov wrote:
Let's say someone defines a macro "_bindirmacro", and actually starts using it in a spec-files. Then there will be an ambiguity during substituting %_bindirmacro - is this %{_bindir}macro or %{_bindirmacro}? Adding brackets will resolve this.
%_bindir will never be substituted in %_bindirmacro. Another thing that comes to mind is mass greps.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/19/2013 05:12 AM, Alexey I. Froloff wrote:
On Fri, Apr 19, 2013 at 01:00:31PM +0400, Peter Lemenkov wrote:
Let's say someone defines a macro "_bindirmacro", and actually starts using it in a spec-files. Then there will be an ambiguity during substituting %_bindirmacro - is this %{_bindir}macro or %{_bindirmacro}? Adding brackets will resolve this.
%_bindir will never be substituted in %_bindirmacro. Another thing that comes to mind is mass greps.
You're right, but someone might think it will. Using the brackets clears up any ambiguity as to what is the macro and what isn't, especially in combined strings.
The brackets also allow for more complicated conditional actions.
~tom
== Fedora Project
On Wed, 24 Apr 2013 14:06:26 -0400, Tom Callaway wrote:
On 04/19/2013 05:12 AM, Alexey I. Froloff wrote:
On Fri, Apr 19, 2013 at 01:00:31PM +0400, Peter Lemenkov wrote:
Let's say someone defines a macro "_bindirmacro", and actually starts using it in a spec-files. Then there will be an ambiguity during substituting %_bindirmacro - is this %{_bindir}macro or %{_bindirmacro}? Adding brackets will resolve this.
%_bindir will never be substituted in %_bindirmacro. Another thing that comes to mind is mass greps.
You're right,
Just for the record, something like
echo "FU=BAR" > %nameconfig.ini echo "FU=BAR" > %name2.conf
still does not expand as one might think even with %{name} being define by default.
So, please use explicit braces/brackets more often than not.
On Fri, 19 Apr 2013 12:53:06 +0400, Alexey I. Froloff wrote:
OTOH, %configure is also a macro, but it is widely used without curly brackets.
Bad comparison, because %configure is always separated with spaces from the rest. The brackets don't add any value there. Even if you "%define config blubb", or something to that effect, that won't cause %configure to be expanded incorrectly.
Michael Schwendt wrote, at 04/25/2013 04:16 AM +9:00:
On Fri, 19 Apr 2013 12:53:06 +0400, Alexey I. Froloff wrote:
OTOH, %configure is also a macro, but it is widely used without curly brackets.
Bad comparison, because %configure is always separated with spaces from the rest. The brackets don't add any value there. Even if you "%define config blubb", or something to that effect, that won't cause %configure to be expanded incorrectly.
Note that (as far as I am correct) there is a case where wrapping with brackets causes wrong (unexpected) behavior when macro takes arguments: http://lists.fedoraproject.org/pipermail/packaging/2011-August/007898.html
For example with rubygem-devel installed and on F-19, i686:
$ rpm --eval "%gem_install -n foobar.gem"
mkdir -p ./usr/share/gems
CONFIGURE_ARGS="--with-cflags='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables' $CONFIGURE_ARGS" \ gem install \ -V \ --local \ --install-dir ./usr/share/gems \ --bindir ./usr/bin \ --force \ --document=ri,rdoc \ foobar.gem
v.s. $ rpm --eval "%{gem_install} -n foobar.gem"
mkdir -p ./usr/share/gems
CONFIGURE_ARGS="--with-cflags='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables' $CONFIGURE_ARGS" \ gem install \ -V \ --local \ --install-dir ./usr/share/gems \ --bindir ./usr/bin \ --force \ --document=ri,rdoc \ %{gem_name}-%{version}.gem -n foobar.gem
Regards, Mamoru
On Thu, Apr 25, 2013 at 07:33:20AM +0900, Mamoru TASAKA wrote:
$ rpm --eval "%{gem_install} -n foobar.gem"
And rpm --eval "%{gem_install -n foobar.gem}" expands correctly. Yes, I am aware how RPM expands macros.
But my question was - CAN I use %macro in specs, or I MUST use %{macro} form always, with exception for %configure (and what else?) ?
On Thu, Apr 25, 2013 at 7:28 AM, Alexey I. Froloff raorn@raorn.name wrote:
On Thu, Apr 25, 2013 at 07:33:20AM +0900, Mamoru TASAKA wrote:
$ rpm --eval "%{gem_install} -n foobar.gem"
And rpm --eval "%{gem_install -n foobar.gem}" expands correctly. Yes, I am aware how RPM expands macros.
But my question was - CAN I use %macro in specs, or I MUST use %{macro} form always, with exception for %configure (and what else?) ?
As long as it's surrounded by whitespace, or separated from other macros by their own '%' symbls or other separators like "/" , you should be OK. The point of guidelines is to provide standards and legibility, not to force every tool in the world to be written only one way.
-- Regards, -- Sir Raorn. --- http://thousandsofhate.blogspot.com/
-- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
On Thu, Apr 25, 2013 at 4:28 AM, Alexey I. Froloff raorn@raorn.name wrote:
And rpm --eval "%{gem_install -n foobar.gem}" expands correctly.
Note that some macros that appear to take arguments actually just expand to a program that takes arguments. For instance, %{configure --disable-foo} will not work, while %{configure} --disable-foo will work. (This case is obvious, but there are some that aren't.)
So it's always a good idea to omit the curly braces when macros accept arguments, just to be safe.
Yes, I am aware how RPM expands macros.
But my question was - CAN I use %macro in specs, or I MUST use %{macro} form always, with exception for %configure (and what else?) ?
I'm not aware of anything in the Packaging Guidelines that dictate which notation you must use, so you may use either as long as it is valid.
-T.C.
packaging@lists.fedoraproject.org