[Guidelines Change] Changes to the Packaging Guidelines

[Tom Callaway]

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_Orde...

---

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_an...


---

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#B...

---

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

[Michael Schwendt]

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.

-- 
$ rpm --eval %__ln_s
ln -s
$ rpm --eval %__ln
%__ln

[Toshio Kuratomi]

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_cor...

-Toshio