From Fedora Project Wiki
(New page: == Addition to ReviewGuidelines == SHOULD: Reviewer should examine an RPM package's list of dependencies and (1) eliminate superfluous explicit ''Requires'' within the spec file and (2) e...)
 
No edit summary
Line 8: Line 8:
Packages should not contain superfluous explicit ''Requires'' within the spec file,  
Packages should not contain superfluous explicit ''Requires'' within the spec file,  
except when absolutely necessary. Any non-superfluous or versioned explicit ''Requires''  
except when absolutely necessary. Any non-superfluous or versioned explicit ''Requires''  
must be explained in comments in the spec file.
should be explained in comments in the spec file.


In particular, we rely on rpmbuild's automatically added dependencies on library SONAMEs.  
In particular, we rely on rpmbuild's automatically added dependencies on library SONAMEs.  

Revision as of 17:11, 20 January 2009

Addition to ReviewGuidelines

SHOULD: Reviewer should examine an RPM package's list of dependencies and (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

Packages should not contain superfluous explicit Requires within the spec file, except when absolutely necessary. Any non-superfluous or versioned explicit Requires should be explained in comments in the spec file.

In particular, we rely on rpmbuild's automatically added 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, after renaming a packge, virtual package names are not kept forever).

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 versioned dependency as appropriate to avoid that it becomes inaccurate and superfluous.