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
-develpackages that is not noarch to another-develpackage. - 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.
- 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:
- For each architecture, rebuild the SRPM first (a relatively cheap operation) and then query it.
- 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)