PackagingDrafts/ArchSpecificRequires

This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

The Problem

rpm and yum treat a dependency on a package (Requires: foo) as being fulfilled by any available package foo, regardless of arch. On multilib systems such as x86_64 there are often two packages with the same name, one for each of the multilib arches. When yum is asked to satisfy a dependency for that package name it could pull in the package for the wrong arch. This is most often encountered when the package for the opposite arch is already installed.

If a dependency really can be satisfied by a build for any architecture there's no reason to make the dependency architecture-specific. These are the scenarios where it does matter:

• A library in the dependency is dlopen'd. (This includes plugins and libraries detected at runtime).
• The dependency from one -devel packages that is not noarch to another -devel package.
• A non-noarch subpackage's dependency on its main package (Eg. libfoo-devel depends on libfoo, or fooapp-plugins depends on foo-app).

Packages MUST add the arch specific dependency in those cases.

In most cases, adding an arch specific dependency unnecessarily will not cause problems. There are a few, however, that must be avoided:

• A package has a Build-Requires on a specific arch. library (because rpmbuild evaluates the %{_isa} at .src.rpm buildtime, and not at .src.rpm => .arch.rpm build time).
• Specifying an arch specific dependency on a package that is noarch.

Making Requires Arch-Specific

The way to make a package dependency arch-specific is by appending the macro %{?_isa} to the package name. For instance,

Requires: foo

becomes

Requires: foo%{?_isa}

...full documentation can be seen at The rpm Wiki page, on Arch requires.

Question

• Does the MUST only apply to libraries? Since apps are usually not multilib I'm unclear if they should be included as a MUST or if they fall in the doesn't helo or hurt category.
• Added specifying an arch specific dep on a noarch package as causing problems. Is that true?