From Fedora Project Wiki
(Only for libraries; rewording about comments)
 
(13 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== Addition to ReviewGuidelines ==
== Addition to ReviewGuidelines ==


SHOULD: Reviewer should examine an RPM package's list of dependencies and
MUST: A package's list of dependencies must not contain any unnecessary explicit Requires on libraries.
(1) eliminate superfluous explicit ''Requires'' within the spec file and
(2) ensure that any non-superfluous or versioned explicit ''Requires'' are explained in comments in the spec file.


== Addition to Packaging Guidelines ==
== Addition to Packaging Guidelines ==
Packages should not contain superfluous explicit ''Requires'' within the spec file,
except when absolutely necessary. Any explicit ''Requires'' should be explained with comments in the spec file.


In particular, we rely on rpmbuild's automatically added dependencies on library SONAMEs.  
=== Explicit Requires ===
Packages must not contain explicit ''Requires'' on libraries except when absolutely
necessary. When explicit library ''Requires'' are necessary, there should be a spec file comment justifying it.
 
We generally rely on rpmbuild to automatically add dependencies on library SONAMEs.  
Modern package management tools are capable of resolving such dependencies to determine  
Modern package management tools are capable of resolving such dependencies to determine  
the required packages. Explicit dependencies on specific package names may aid the  
the required packages. Explicit dependencies on specific package names may aid the  
inexperienced user, who attempts at installing RPM packages manually. However, history  
inexperienced user, who attempts at installing RPM packages manually, however, history  
has shown that such dependencies add confusion when library/files are moved from one  
has shown that such dependencies add confusion when library/files are moved from one  
package to another, when packages get renamed, when one out of multiple alternative  
package to another, when packages get renamed, when one out of multiple alternative  
packages would suffice, and when versioned explicit dependencies become out-of-date and  
packages would suffice, and when versioned explicit dependencies become out-of-date and  
inaccurate. Additionally, in some cases, old explicit dependencies on package names  
inaccurate. Additionally, in some cases, old explicit dependencies on package names  
require unnecessary updates/rebuilds (for example, after renaming a packge, virtual
require unnecessary updates/rebuilds. For example, Fedora packages are only required
package names are not kept forever).
to retain historical provides for two full release cycles.


Exemplary rationale for a versioned explicit dependency:
Exemplary rationale for a versioned explicit dependency:
Line 27: Line 27:
</pre>
</pre>


Packagers should revisit an explicit versioned dependency as appropriate to avoid that
Packagers should revisit an explicit dependency as appropriate to avoid  
it becomes inaccurate and superfluous.
it becoming inaccurate and superfluous. For instance in the example above, when no current Fedora release shipped with libfubar < 1.2.3-7, it is no longer necessary to list the explicit, versioned requirement.
 
[[Category:Packaging guidelines drafts]]

Latest revision as of 16:49, 22 February 2009

Addition to ReviewGuidelines

MUST: A package's list of dependencies must not contain any unnecessary explicit Requires on libraries.

Addition to Packaging Guidelines

Explicit Requires

Packages must not contain explicit Requires on libraries except when absolutely necessary. When explicit library Requires are necessary, there should be a spec file comment justifying it.

We generally rely on rpmbuild to automatically add dependencies on library SONAMEs. Modern package management tools are capable of resolving such dependencies to determine the required packages. Explicit dependencies on specific package names may aid the inexperienced user, who attempts at installing RPM packages manually, however, history has shown that such dependencies add confusion when library/files are moved from one package to another, when packages get renamed, when one out of multiple alternative packages would suffice, and when versioned explicit dependencies become out-of-date and inaccurate. Additionally, in some cases, old explicit dependencies on package names require unnecessary updates/rebuilds. For example, Fedora packages are only required to retain historical provides for two full release cycles.

Exemplary rationale for a versioned explicit dependency:

  # The automatic dependency on libfubar.so.1 is insufficient,
  # as we strictly need at least the release that fixes two segfaults.
  Requires: libfubar >= 0:1.2.3-7

Packagers should revisit an explicit dependency as appropriate to avoid it becoming inaccurate and superfluous. For instance in the example above, when no current Fedora release shipped with libfubar < 1.2.3-7, it is no longer necessary to list the explicit, versioned requirement.