m (Add other common case x-64 installed but x-32 desired.) |
|||
| Line 2: | Line 2: | ||
== Rationale == | == Rationale == | ||
rpm/yum treat a dependency (Requires) on “foo” as satisfiable by any available foo, regardless of architecture. The consequence of this is that on multilib systems, when the architecture of a dependency has not been specified (even though it is important), yum can install the wrong architecture build of the dependency—resulting in, most likely, a nonfunctional installation. This | rpm/yum treat a dependency (Requires) on “foo” as satisfiable by any available foo, regardless of architecture. The consequence of this is that on multilib systems, when the architecture of a dependency has not been specified (even though it is important), yum can install the wrong architecture build of the dependency—resulting in, most likely, a nonfunctional installation. This can happen when, for some reason, the correct architecture is not available to yum or (somewhat more importantly) the opposite arch. than the one desired is already installed. | ||
== Making Requires Arch-Specific == | == Making Requires Arch-Specific == | ||
Revision as of 17:56, 10 May 2010
It is still under construction and content may change. Do not rely on the information on this page.
Rationale
rpm/yum treat a dependency (Requires) on “foo” as satisfiable by any available foo, regardless of architecture. The consequence of this is that on multilib systems, when the architecture of a dependency has not been specified (even though it is important), yum can install the wrong architecture build of the dependency—resulting in, most likely, a nonfunctional installation. This can happen when, for some reason, the correct architecture is not available to yum or (somewhat more importantly) the opposite arch. than the one desired 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}
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.
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.