PackagingDrafts/ArchSpecificRequires

From FedoraProject

< PackagingDrafts(Difference between revisions)
Jump to: navigation, search
(Making Requires Arch-Specific)
(When To Do It)
Line 20: Line 20:
 
* A non-noarch subpackage's dependency on its main package.
 
* 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, you MUST do it.
+
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.

Revision as of 13:45, 10 May 2010

Warning (medium size).png
This page is a draft only
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 appears to happen when, for some reason, the correct architecture is not available to yum.

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 -devel package depends on another -devel package.
  • 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.