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 that is explicitly Required (example a dlopen'd library)
• 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 NOT be made arch specific:

• 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?
• If we don't use arch-specific BuildRequires, then there is nothing preventing the same kinds of problems from happening as with Requires (although maybe they are less frequent with mock usually starting from a minimal buildroot). We ought to find a way to get the BuildRequires evaluated properly for each architecture. Some possible approaches:
  1. For each architecture, rebuild the SRPM first (a relatively cheap operation) and then query it.
  2. Add a new query tag so that "rpm -q --specfile" can query BuildRequires, and then use that for each architecture.

Mattmccutchen 03:17, 3 June 2010 (UTC)