Bug 235755 - rpm doesn't allow 'Requires: foo.%{ARCH}'
rpm doesn't allow 'Requires: foo.%{ARCH}'
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Panu Matilainen
:
: 203080 212523 216025 234446 (view as bug list)
Depends On:
Blocks: multilib 235756
  Show dependency treegraph
 
Reported: 2007-04-09 18:46 EDT by David Woodhouse
Modified: 2009-06-10 05:31 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-14 07:52:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Woodhouse 2007-04-09 18:46:27 EDT
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-09 21:53:59 EDT
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 07:32:29 EDT
Please add comments to

    https://lists.dulug.duke.edu/pipermail/rpm-devel/2007-April/002260.html
Comment 3 Jeff Johnson 2007-04-29 08:45:13 EDT
Comment added so that I can find this bug in spite of bugzilla normal -> medium churn.
Comment 4 David Woodhouse 2007-04-30 08:37:45 EDT
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 11:27:34 EDT
The additional piece that yum likely *will* be happy with is translating
    Requires: %{_libdir}/libbar.so
intp
    Requires: libbar.so()(64bit)
or
    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 11:29:04 EDT
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 12:50:23 EDT
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 12:51:53 EDT
I'll whack a --follow option into rpmdeps, not hard.
Comment 9 Kevin Kofler 2007-04-30 22:30:35 EDT
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-01 21:20:23 EDT
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
filelists.gz.

So there's no need to explain ...
Comment 11 Jeff Johnson 2007-05-02 08:16:57 EDT
If you want
    Requires: name.arch
implemented, please add comments at
    https://lists.dulug.duke.edu/pipermail/rpm-devel/2007-May/002505.html
Comment 12 Jeff Johnson 2007-05-04 23:53:51 EDT
Added in rpm cvs, will be in rpm-4.4.9-0.5 when built.

UPSTREAM
Comment 13 Panu Matilainen 2007-07-18 15:03:48 EDT
*** Bug 234446 has been marked as a duplicate of this bug. ***
Comment 14 Panu Matilainen 2007-07-18 15:04:20 EDT
*** Bug 212523 has been marked as a duplicate of this bug. ***
Comment 15 Panu Matilainen 2007-08-07 07:23:01 EDT
*** Bug 203080 has been marked as a duplicate of this bug. ***
Comment 16 Panu Matilainen 2007-08-10 03:02:09 EDT
*** Bug 216025 has been marked as a duplicate of this bug. ***
Comment 17 Red Hat Bugzilla 2007-08-21 01:33:27 EDT
User pnasrat@redhat.com's account has been closed
Comment 18 Panu Matilainen 2007-08-22 02:29:47 EDT
Reassigning to owner after bugzilla made a mess, sorry about the noise...
Comment 19 Panu Matilainen 2008-04-15 07:15:34 EDT
Fixed in upstream rpm.org, but somewhat differently from all the variants
discussed here. See
http://devel.linux.duke.edu/gitweb/?p=rpm.git;a=commit;h=48ff62a5291458ed1181cd6c31dcadb193ad2f8e
for details.
Comment 20 Bug Zapper 2008-05-13 22:45:17 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 22 Panu Matilainen 2008-06-10 05:00:20 EDT
Ain't going to be fixed in F9, moving back to rawhide...
Comment 23 Panu Matilainen 2008-07-14 07:52:41 EDT
New rpm implementing what's described in comment #19 is in rawhide now...
Comment 24 Stepan Kasal 2009-06-10 04:41:47 EDT
(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 05:31:59 EDT
See http://rpm.org/wiki/PackagerDocs/ArchDependencies

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