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 appears to happen when the correct architecture is not available to yum.

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 or another subpackage (e.g., 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.

Suggested modifications to the Packaging Guidelines

Requires

[Change the second sentence of paragraph 6 to:]

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.

[Change paragraph 7 to:]

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

 Requires: foo

becomes

 Requires: foo%{?_isa}

This means that gtk+ devel should contain

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

Explicit Requires

[Append to the first paragraph:]

Explicit library dependencies should typically be arch-specific (unless the packages involved are noarch).

[Change the example for a versioned explicit dependency to:]

 # The automatic dependency on libfubar.so.1 is insufficient,
 # as we strictly need at least the release that fixes two segfaults.
 Requires: libfubar%{?_isa} >= 0:1.2.3-7

Requiring Base Package

[Change to:]

Devel packages must require the base package using a fully versioned arch-specific (for non-noarch packages) dependency:

 Requires: %{name}%{_isa} = %{version}-%{release}

Usually, subpackages other than -devel should also require the base package using a fully versioned arch-specific dependency.

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.

Mattmccutchen 03:17, 3 June 2010 (UTC)

Both applications and libraries can dlopen modules; and thus the same rules apply when dealing with such a dependency.

If you're asking about depending on applications, the answer is: they usually should not be arch-specific; but it depends. Specifically, there are some conceivable edge cases where it would matter: e.g., my package consumes the output of a program whose output varies depending on the arch.

Braden 3:55, 19 June 2010 (UTC)

• Added specifying an arch specific dep on a noarch package as causing problems. Is that true?

Mattmccutchen 03:17, 3 June 2010 (UTC)

I'm pretty sure it is, since the arch of a noarch package is "noarch"; and thus nothing else is going to match. And while it's accurate that an unnecessary arch-specific Require is unlikely to be harmful (as long as it actually resolves to something), I'd prefer to avoid wording that might lead folks to think that it's okay to naively make their Requires arch-specific "just in case".

Braden 3:55, 19 June 2010 (UTC)

• 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)

I'm less concerned with this case because it doesn't impact Fedora end users the same way. If Fedora's package build system pulls down the wrong build dependency, then presumably the build fails. The package maintainer then waits for the system to right itself and then tries again. By contrast, Requires that aren't properly arch-specific can result in users getting packages that don't work together. So I'd prefer to address the issue of BuildRequires separately."

Braden 3:55, 19 June 2010 (UTC)