On Tue, Mar 22, 2011 at 11:53:47AM +0100, Michael Schwendt wrote:
On Mon, 21 Mar 2011 21:40:43 -0400, Tom wrote:
Macro forms of system executables (such as %{__rm}) should not be used except when there is a need to allow the location of those executables to be configurable.
rm should be used in preference to %{__rm}, but %{__python} is acceptable.
Hmmm... where's the rationale? The "why?"s aren't answered. One truth about macro-fied commands is that typically the packagers don't ensure consistency throughout the entire build process. For example, "configure" scripts and Makefiles pick up their own commands based on $PATH (or other techniques) or hardcode plain path-less commands in at least a few files. Nothing ensures that the value of %__rm and similar macros are passed on to the build framework. Using %__python is not acceptable either in that case. Unless a redefinition of %__python makes sure that nothing else than the expanded value is used throughout the entire build process *and* also inside RPM scriptlets.
If a packager sees "a need to allow the location of those executables to be configurable", the spec file ought to (or MUST?) give an explanation in a comment. Only that helps with fighting macro-madness.
The reason that the value of __python is mentioned is that it is being used in the python guidelines as a marker for which version of python (2 or 3) to byte compile for. Otherwise, the case for %{__python} would be no better than for %{__rm}.
http://fedoraproject.org/wiki/Packaging:Python#Bytecompiling_with_the_correc...
-Toshio