From Fedora Project Wiki

< User:Tibbs

Revision as of 18:25, 21 February 2017 by Tibbs (talk | contribs) (Initial guideline page import.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Package dependencies

RPM has very good capabilities of automatically finding dependencies for libraries and eg. Perl modules. In short, don't reinvent the wheel, but just let rpm do its job. There is usually no need to explicitly list eg. Requires: libX11 when the dependency has already been picked up by rpm in the form of depending on libraries in the libX11 package.

Build requirements are different. There's no automatic dependency find procedure for them, which means that you must explicitly list stuff that the package requires to build successfully. Typically, some -devel packages are listed there. Refer to the BuildRequires section .

Sometimes we know that a package requires eg. gtk+-devel 1.2 or newer to build (and thus gtk+ 1.2 or newer to run, but that's handled automatically). There are two things to consider here:

First, if the lowest possible requirement is so old that nobody has a version older than that installed on any target distribution release, there's no need to include the version in the dependency at all. In that case we know the available software is new enough. For example, the version in gtk+-devel 1.2 dependency above is unnecessary for all Red Hat Linux distributions since (at least) release 6.2. As a rule of thumb, if the version is not required, don't add it just for fun.

Second, the Epoch (if used) must be listed when adding a versioned dependency to achieve robust epoch-version-release comparison. See #Use_of_Epochs for details. A quick way to check the Epoch of package foo is to run:

rpm --query --qf "%{EPOCH}\n" packagename

Typically, the requirements for -devel packages need yet another look. They're not usually picked up automatically by rpm; and unless the generated RPMs will be noarch, -devel package dependencies on other -devel packages should be arch-specific.

A dependency is made arch-specific by appending the macro %{?_isa} to the package name. For example:

Requires: foo


Requires: foo%{?_isa}

If the foo-devel package has a foo-config script, you can try doing a foo-config --libs and foo-config --cflags to get strong hints what packages should be marked as foo's requirements. For example:

$ gtk-config --cflags
-I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include
$ gtk-config --libs
-L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm

This means that gtk+-devel should contain

Requires: glib-devel%{?_isa} libXi-devel%{?_isa} libXext-devel%{?_isa} libX11-devel%{?_isa}

Weak dependencies

Weak dependencies (Recommends:, Suggests:, Supplements: and Enhances:) can be used to specify relationships between packages which are less strict than mandatory requirements. Please see Packaging:WeakDependencies for guidelines on using these tags.

Rich/Boolean dependencies

Packages may make limited use of the rich (or Boolean) dependency feature [[1]] supported in RPM. They may be used in Suggests:, Enhances: and Supplements: dependencies. However they may not currently be used in Requires: or Recommends: dependencies as this will cause issues with the package updates process.

File Dependencies

RPM gives you the ability to depend on files instead of packages. Whenever possible you should avoid file dependencies as they slow down dependency resolution and require the package manager to download file lists in addition to to regular dependency information. There are, however, times when other technical considerations outweigh these considerations. If the files you need are prone to moving between packages of different names, it can be useful to depend on those files directly.

Explicit Requires

Explicit Requires are Requires added manually by the packager in the spec file. Packages must not contain unnecessary explicit Requires on libraries. 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 in many cases. However, present versions of rpmbuild only add deps on library SONAMES, not the library's full version. This can be a problem if a library has added features over the course of time without backwards incompatibilities that would cause SONAMES to be changed. This can lead to a case where the user has an old version of a library installed, the new version of the library with new ABI is built in Fedora and an application using that ABI is built. If the user just attempts to install or update that one application without also updating the library, the application will install fine (because the SONAME dependency is satisfied) but will fail when run because the library installed on the system is missing features it needs.

Although you do need to add explicit library dependencies to keep this from occurring, there are drawbacks to manually specifying this in all your packages. 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.

Because of this and because we hope to have this fixed in rpmbuild, this is something to be aware of but it's not required that you explicitly specify the libraries you require with their version information.

When explicit library Requires are necessary, explicit library dependencies should typically be arch-specific (unless the packages involved are noarch) and there should be a spec file comment justifying it:

# The automatic dependency on is insufficient,
# as we strictly need at least the release that fixes two segfaults.
Requires: libfubar%{?_isa} >= 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.

Filtering Auto-Generated Requires

RPM attempts to auto-generate Requires (and Provides) at build time, but in some situations, the auto-generated Requires/Provides are not correct or not wanted. For more details on how to filter out auto-generated Requires or Provides, please see: Packaging:AutoProvidesAndRequiresFiltering