m (Make this more succinct but still informative) |
|||
| Line 1: | Line 1: | ||
{{Draft}} | {{Draft}} | ||
== | == The Problem == | ||
<code>rpm</code> and <code>yum</code> treat a dependency on a package (<code>Requires: foo</code>) as being fulfilled by any available package <code>foo</code>, 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. | <code>rpm</code> and <code>yum</code> treat a dependency on a package (<code>Requires: foo</code>) as being fulfilled by any available package <code>foo</code>, 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. | ||
Revision as of 15:59, 26 May 2010
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.
Making Requires Arch-Specific
Explicit requires must be made arch-specific 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.
When To Do It
If a dependency really can be satisfied by a build for any architecture, clearly there's no reason to make the dependency architecture-specific. But it does matter in these scenarios:
- A library in the dependency is
dlopen'd. - A non-noarch
-develpackage depends on another-develpackage. - A non-noarch subpackage's dependency on its main package (Eg. libfoo-devel depends on libfoo).
So, unless you have a very good reason to not make an explicit dependency architecture specific (and if so, be sure to document it in the spec file with a comment), you MUST do it.
When NOT To Do It
Making a general requirement more specific rarely produces significant problems. However there is at least one scenario where you should never use arch. specific requires:
- 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).