$ 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.
On 2010-08-27, Pavel Alexeev (aka Pahan-Hubbitus) forum@hubbitus.com.ru 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
27.08.2010 13:08, Petr Pisar ?????:
On 2010-08-27, Pavel Alexeev (aka Pahan-Hubbitus) forum@hubbitus.com.ru 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
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
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