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 of the form 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 happens when the correct architecture is not available to yum. That might be the case if, due to some malfunction, the Fedora repositories are out of synch. It can also happen if a user has installed a package that is treated as "newer" than the corresponding package in the currently enabled set of repositories; in attempting to resolve otherwise-unresolvable dependency chains, yum may decide to pull in the dependency chain for a different arch.

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.

Suggested modifications to the Naming Guidelines

Renaming/replacing existing packages

[Add after paragraph 5:]

Provides needs to be aware of whether the package is supplying things can be used in an arch-independent or arch-specific fashion. For packages that are not noarch, Provides should be made arch-specific by applying the %{?_isa} macro. Packages that provide things that can be used in an arch-independent way—i.e., packages whose dependents need not necessarily be of an identical arch—need not apply this macro. In some cases, a package will supply different elements, some of which may be consumed only by dependents of an identical arch, and some with may be consumed by dependents of any arch. In such cases, both arch-specific and arch-independent Provides are warranted.

Examples of packages that should provide only arch-specific Provides include native code libraries or plug-ins and their associated -devel packages. Packages that should provide only arch-independent Provides include most stand-alone programs (in addition to all noarch packages). Even though these programs may themselves be arch-specific, clients than run them normally should not care about their arch. A package that provides, for example, both a native code library as well as an interpreted language interface to that library should provide both arch-specific (for clients of the native code library) and arch-independent (for clients of the interpreted language interface) Provides.

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)