(Split non-obvious items from explict requires) |
|||
| Line 30: | Line 30: | ||
Packagers should revisit an explicit dependency as appropriate to avoid that | Packagers should revisit an explicit dependency as appropriate to avoid that | ||
it becomes inaccurate and superfluous. | it becomes inaccurate and superfluous. | ||
[[Category:Packaging guidelines drafts]] | |||
Revision as of 21:34, 17 February 2009
Addition to ReviewGuidelines
MUST: An RPM package's list of dependencies must not contain any unnecessary explicit Requires.
Addition to Packaging Guidelines
Explicit Requires
Packages must not contain explicit Requires within the spec file, except when absolutely necessary. Any non-obvious explicit Requires should be explained with 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, 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 that it becomes inaccurate and superfluous.