Bug 235755 - rpm doesn't allow 'Requires: foo.%{ARCH}'
Summary: rpm doesn't allow 'Requires: foo.%{ARCH}'
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact:
: 203080 212523 216025 234446 (view as bug list)
Depends On:
Blocks: multilib 235756
TreeView+ depends on / blocked
Reported: 2007-04-09 22:46 UTC by David Woodhouse
Modified: 2009-06-10 09:31 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-07-14 11:52:41 UTC
Type: ---

Attachments (Terms of Use)

Description David Woodhouse 2007-04-09 22:46:27 UTC
We need to be able to indicate that a given package depends on another package
of a specific architecture.

For example, if 'foo-devel' depends on 'bar-devel', it really needs 'bar-devel'
of the _same_ architecture. Yet in a multilib environment, you often see these
dependencies being satisfied by packages of the wrong architecture.

Comment 1 Jeff Johnson 2007-04-10 01:53:59 UTC
This automagically happens for soname dependencies.

Do you have a non-trivial non-elf real-world example where a dependency
on arch is useful?

FWIW, there's nothing at all stopping you from adding matched pairs of
    Provides: foo.arch
    Requires: foo.arch
to existing packaging.

Adding a Provides: N.A = E:V-R to every package is like 4 lines of code.

Making the Provides: appear from existing header information is equally trivial.

Comment 2 Jeff Johnson 2007-04-11 11:32:29 UTC
Please add comments to


Comment 3 Jeff Johnson 2007-04-29 12:45:13 UTC
Comment added so that I can find this bug in spite of bugzilla normal -> medium churn.

Comment 4 David Woodhouse 2007-04-30 12:37:45 UTC
One possibility might be to avoid dependencies on 'bar-devel' and instead
require %{_libdir}/libbar.so -- or does yum have problems with that?

Comment 5 Jeff Johnson 2007-04-30 15:27:34 UTC
The additional piece that yum likely *will* be happy with is translating
    Requires: %{_libdir}/libbar.so
    Requires: libbar.so()(64bit)
    Requires: libbar.so

I'd suggest wrapping the gook into a buildtime probe like, say,
   Requires: getsonamedependency(%{_libdir)/libbar.so)
to dig out the soname from a path to elf library at build (not install) time.

Comment 6 Jeff Johnson 2007-04-30 15:29:04 UTC
In fact, I can think of a whole class of useful build time probe transaltions.

On my rpm todo++ ...

Comment 7 Jeff Johnson 2007-04-30 16:50:23 UTC
OTOH, I'm a lazy schmuck.

Except for annoying symlink dereferences, this snippet of code will add
the soname dependencies (with pugly "...()(64bit)" suffixes) as a package
requirement. Let's say "bar" == "popt" and I want to add a dependency
on the sonames of the library contained on the path %{_libdir}/libpopt.so.0.0.0

Adding to foo-devel
    Requires: %(echo %{_libdir}/libpopt.so.0.0.0 | /usr/lib/rpm/rpmdeps -P)
will add dependencies in the binary foo-devel package (on ix86)
    Requires: libpopt.so.0
    Requires: libpopt.so.0(LIBPOPT_0)
with appropriately marked analogues on elf64 systems.

Hmmm, no coloring, but then you don't want colored dependencies, correct?

Comment 8 Jeff Johnson 2007-04-30 16:51:53 UTC
I'll whack a --follow option into rpmdeps, not hard.

Comment 9 Kevin Kofler 2007-05-01 02:30:35 UTC
The idea here is actually to have a dependency on the -devel package, which 
means the dependency is really wanted on the .so symlink (which is in 
the -devel package), NOT on the .so.n or .so.x.y.z file (which are in the main 
package), so following the symlink is actually the wrong thing to do. The 
dependencies on the main packages are already nicely taken care of by the 
Autoreq feature, it's dependencies like "foo-devel Requires: bar-devel" which 
are a problem.

Comment 10 Jeff Johnson 2007-05-02 01:20:23 UTC
There's nothing stopping anyone from adding a file dependency
   Requires: %{_libdir}/libbar.so
to libfoo-devel to spepecify a dependency on libbar-devel of same arch.

All the above was an alternative means to assist yum in not downloading
file paths. In fact, there is already a hack in rpm to connect a libfoo.so symlink
to an soname, not a path, for the same reasons, avoiding downloading

So there's no need to explain ...

Comment 11 Jeff Johnson 2007-05-02 12:16:57 UTC
If you want
    Requires: name.arch
implemented, please add comments at

Comment 12 Jeff Johnson 2007-05-05 03:53:51 UTC
Added in rpm cvs, will be in rpm-4.4.9-0.5 when built.


Comment 13 Panu Matilainen 2007-07-18 19:03:48 UTC
*** Bug 234446 has been marked as a duplicate of this bug. ***

Comment 14 Panu Matilainen 2007-07-18 19:04:20 UTC
*** Bug 212523 has been marked as a duplicate of this bug. ***

Comment 15 Panu Matilainen 2007-08-07 11:23:01 UTC
*** Bug 203080 has been marked as a duplicate of this bug. ***

Comment 16 Panu Matilainen 2007-08-10 07:02:09 UTC
*** Bug 216025 has been marked as a duplicate of this bug. ***

Comment 17 Red Hat Bugzilla 2007-08-21 05:33:27 UTC
User pnasrat@redhat.com's account has been closed

Comment 18 Panu Matilainen 2007-08-22 06:29:47 UTC
Reassigning to owner after bugzilla made a mess, sorry about the noise...

Comment 19 Panu Matilainen 2008-04-15 11:15:34 UTC
Fixed in upstream rpm.org, but somewhat differently from all the variants
discussed here. See
for details.

Comment 20 Bug Zapper 2008-05-14 02:45:17 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:

Comment 22 Panu Matilainen 2008-06-10 09:00:20 UTC
Ain't going to be fixed in F9, moving back to rawhide...

Comment 23 Panu Matilainen 2008-07-14 11:52:41 UTC
New rpm implementing what's described in comment #19 is in rawhide now...

Comment 24 Stepan Kasal 2009-06-10 08:41:47 UTC
(In reply to comment #23)
> New rpm implementing what's described in comment #19 is in rawhide now...  

Unfortunately, comment #19 describes nothing; it only contains a broken link.
Would you care pasting a description here?

Comment 25 Panu Matilainen 2009-06-10 09:31:59 UTC
See http://rpm.org/wiki/PackagerDocs/ArchDependencies

Note You need to log in before you can comment on or make changes to this bug.