Question about sane usage of macroses in perl template

[Pavel Alexeev]

 $ rpmdev-newspec -t perl
produce template where, inter alia we have such lines:
%{__perl} Makefile.PL INSTALLDIRS=vendor
OPTIMIZE="$RPM_OPT_FLAGS"                                                       
                                                                       

make %{?_smp_mflags}

I'm wonder why there used mix of macros %{__perl} and plain other
commands like make?
Rpm say it is just perl command with path:
$ rpm --eval '%{__perl}'
/usr/bin/perl
Is there any advantage for that?

Many reviewers say what one form should be used if no explicit
requirements for other way.

Also we have Review Guidelins which say usage of macroses should be
consistent -
http://fedoraproject.org/wiki/Packaging:ReviewGuidelines#cite_note-15.
At my point it is example of such "inconsistent" there.

-- 

With best wishes, Pavel Alexeev aka Pahan-Hubbitus.
For fast contact with me you could use Jabber: Hubbitus(a)jabber.ru

[Petr Pisar]

On 2010-08-27, Pavel Alexeev (aka Pahan-Hubbitus) <forum(a)hubbitus.com.ru&gt; wrote:
>  %{__perl} Makefile.PL INSTALLDIRS=vendor
>  OPTIMIZE="$RPM_OPT_FLAGS"
>
>  make %{?_smp_mflags}
>
>  I'm wonder why there used mix of macros %{__perl} and plain other
>  commands like make? 
Because you cannot have macro for each shell command. (Actually you can,
but it would be silly). Personally, I don't like aliasing macros and
I prefer direct commands as it's simpler and more readable.


>  Rpm say it is just perl command with path:
>  $ rpm --eval '%{__perl}'
>  /usr/bin/perl
>  Is there any advantage for that?
>  
Probably perl interpreter had been in other location or under diferrent
name before. (E.g. transition between two incompatible perl versions).
This macro could be used to make easy the transition for package
maintainers. Or there had been used some addition perl arguments (like
-w). Or the macro was defined to allow spec file sharing between
distributions with different perl locations.

However this is just speculation. You need to ask the guy how invented
the macro. (It wasn't me :)

-- Petr

[Pavel Alexeev]

 27.08.2010 13:08, Petr Pisar ?????:
>  On 2010-08-27, Pavel Alexeev (aka Pahan-Hubbitus)
> <forum(a)hubbitus.com.ru&gt; wrote:
> > %{__perl} Makefile.PL INSTALLDIRS=vendor
> > OPTIMIZE="$RPM_OPT_FLAGS"
> >
> > make %{?_smp_mflags}
> >
> > I'm wonder why there used mix of macros %{__perl} and plain other
> > commands like make?
>  Because you cannot have macro for each shell command. (Actually you can,
>  but it would be silly). Personally, I don't like aliasing macros and
>  I prefer direct commands as it's simpler and more readable.
>  
Actually macroses present for most used commands and I also now prefer
plain comments in spec. But it is not main question.
> > Rpm say it is just perl command with path:
> > $ rpm --eval '%{__perl}'
> > /usr/bin/perl
> > Is there any advantage for that?
> >
>  Probably perl interpreter had been in other location or under diferrent
>  name before. (E.g. transition between two incompatible perl versions).
>  This macro could be used to make easy the transition for package
>  maintainers. Or there had been used some addition perl arguments (like
>  -w). Or the macro was defined to allow spec file sharing between
>  distributions with different perl locations.
>
>  However this is just speculation. You need to ask the guy how invented
>  the macro. (It wasn't me :) 
Off course. But question inspired by review
https://bugzilla.redhat.com/show_bug.cgi?id=627024#c2 where main
argument of its usage what it is some sort of standard because it used
in template.
<https://bugzilla.redhat.com/show_bug.cgi?id=627024#c2>
>  -- Petr
>

[Ralf Corsepius]

On 08/27/2010 10:28 AM, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
>    $ rpmdev-newspec -t perl
>  produce template where, inter alia we have such lines:
>  %{__perl} Makefile.PL INSTALLDIRS=vendor
>  OPTIMIZE="$RPM_OPT_FLAGS"
>
>  make %{?_smp_mflags}
>
>  I'm wonder why there used mix of macros %{__perl} and plain other
>  commands like make?
>  Rpm say it is just perl command with path:
>  $ rpm --eval '%{__perl}'
>  /usr/bin/perl
>  Is there any advantage for that? 
You are missing the point:

%__perl is being used to derive a whole zoo of %defines, which required 
to keep perl-module packages consistent - make doesn't.

E.g. all perl-module packages something similar to this:

Requires:  perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
...
%{__perl} Makefile.PL INSTALLDIRS=vendor
...
%{perl_vendorlib}


>  Also we have Review Guidelins which say usage of macroses should be
>  consistent - 
Correct ... when using one macro, it must be used consistently 
throughout a *.spec, otherwise your package will not build correctly 
should a macro change.

In other words, when using %__perl, you must use it everywhere inside of 
your *.spec. As %__perl is being used inside of the default rpm macros, 
not using %__perl almost always will be wrong.


Ralf

[Pavel Alexeev]

 27.08.2010 13:58, Ralf Corsepius пишет:
>  On 08/27/2010 10:28 AM, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
> >   $ rpmdev-newspec -t perl
> > produce template where, inter alia we have such lines:
> > %{__perl} Makefile.PL INSTALLDIRS=vendor
> > OPTIMIZE="$RPM_OPT_FLAGS"
> >
> > make %{?_smp_mflags}
> >
> > I'm wonder why there used mix of macros %{__perl} and plain other
> > commands like make?
> > Rpm say it is just perl command with path:
> > $ rpm --eval '%{__perl}'
> > /usr/bin/perl
> > Is there any advantage for that?
>  You are missing the point:
>
>  %__perl is being used to derive a whole zoo of %defines, which required 
>  to keep perl-module packages consistent - make doesn't.
>
>  E.g. all perl-module packages something similar to this:
>
>  Requires:  perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
>  $version))
>  ...
>  %{__perl} Makefile.PL INSTALLDIRS=vendor
>  ...
>  %{perl_vendorlib}
>
>
> > Also we have Review Guidelins which say usage of macroses should be
> > consistent -
>  Correct ... when using one macro, it must be used consistently 
>  throughout a *.spec, otherwise your package will not build correctly 
>  should a macro change.
>
>  In other words, when using %__perl, you must use it everywhere inside of 
>  your *.spec. As %__perl is being used inside of the default rpm macros, 
>  not using %__perl almost always will be wrong.
>  
Ok, but why not use plain perl?
>  Ralf
>