From Fedora Project Wiki
(make some clarification changes -- two questions to ask, slight loosening of the MUST)
Line 3: Line 3:
== The Problem ==
== 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.
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 in the dependency is <code>dlopen</code>'d.  (This includes plugins and libraries detected at runtime).
* The dependency from one <code>-devel</code> packages that is not noarch to another <code>-devel</code> package.
* 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 be avoided:
* 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 ==
== Making Requires Arch-Specific ==
Explicit requires must be made arch-specific by appending the macro <code>%{?_isa}</code> to the package name.  For instance,
The way to make a package dependency arch-specific is by appending the macro <code>%{?_isa}</code> to the package name.  For instance,


  Requires: foo
  Requires: foo
Line 15: Line 28:
...full documentation can be seen at The rpm Wiki page, on [http://www.rpm.org/wiki/PackagerDocs/ArchDependencies Arch requires].
...full documentation can be seen at The rpm Wiki page, on [http://www.rpm.org/wiki/PackagerDocs/ArchDependencies Arch requires].


== When To Do It ==
== Question ==
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:
* 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?
* A library in the dependency is <code>dlopen</code>'d.
* A non-noarch <code>-devel</code> package depends on another <code>-devel</code> package.
* 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).

Revision as of 16:11, 26 May 2010

Warning.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.

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 in the dependency is dlopen'd. (This includes plugins and libraries detected at runtime).
  • The dependency from one -devel packages that is not noarch to another -devel package.
  • 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 be avoided:

  • 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?
Retrieved from "https://fedoraproject.org/w/index.php?title=PackagingDrafts/ArchSpecificRequires&oldid=176517"