Here are the latest set of changes to the Fedora Packaging Guidelines:
---
The Emacs packaging guidelines were updated to handle cases where a package's principal functionality does not require (X)Emacs, but the package also includes some auxiliary Elisp files to provide support for the package in (X)Emacs.
https://fedoraproject.org/wiki/Packaging:Emacs
---
The Scriptlet Snippets section dealing with the order that scriptlets are invoked has been updated to include %trigger scripts.
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Scriptlet_Orderin...
---
A subsection was added to the Packaging Guidelines section on Filesystem Layout in which it is made explicit that binaries in /bin or /sbin must NOT depend on any libraries in /usr/lib or /usr/lib64.
https://fedoraproject.org/wiki/Packaging:Guidelines#Binaries_in_.2Fbin_and_....
---
The section on Epochs was improved, and clarifying language about Epoch use in Requires was added to the Packaging Guidelines.
https://fedoraproject.org/wiki/Packaging:Guidelines#Use_of_Epochs https://fedoraproject.org/wiki/Packaging:Guidelines#Requires
---
New guidelines were added covering the packaging of Ada programs.
https://fedoraproject.org/wiki/Packaging:Ada
---
The section on Boostrapping in the Treatment of Bundled Libraries page in the Packaging Guidelines has been amended to add the following:
Packages which are built in such a bootstrapping mode must not be tagged for a final release (or pushed as an update for any stable release). FPC will track the progress of approved bootstrapping exceptions via the ticket requesting the bootstrap bundling exception.
https://fedoraproject.org/wiki/Packaging:Treatment_Of_Bundled_Libraries#Boot...
---
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
---
These guidelines (and changes) were approved by the Fedora Packaging Committee (FPC).
Many thanks to Hans Niedermann, Jonathan Underwood, Pavel Zhukov, and all of the members of the FPC, for assisting in drafting, refining, and passing these guidelines.
As a reminder: The Fedora Packaging Guidelines are living documents! If you find something missing, incorrect, or in need of revision, you can suggest a draft change. The procedure for this is documented here: https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure
Thanks,
~spot
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.
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
packaging@lists.fedoraproject.org
-
Michael Schwendt -
Tom Callaway -
Toshio Kuratomi