[Fedora-packaging] [Guidelines Change] Changes to the Packaging Guidelines

Toshio Kuratomi a.badger at gmail.com
Tue Mar 22 15:01:21 UTC 2011


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.
> > 
> > https://fedoraproject.org/wiki/Packaging:Guidelines#Macros
> 
> > 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_correct_python_version

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/packaging/attachments/20110322/8bf45434/attachment.bin 


More information about the packaging mailing list