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
-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.
- Added specifying an arch specific dep on a noarch package as causing problems. Is that true?