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.
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.
Please add comments to https://lists.dulug.duke.edu/pipermail/rpm-devel/2007-April/002260.html
Comment added so that I can find this bug in spite of bugzilla normal -> medium churn.
One possibility might be to avoid dependencies on 'bar-devel' and instead require %{_libdir}/libbar.so -- or does yum have problems with that?
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.
In fact, I can think of a whole class of useful build time probe transaltions. On my rpm todo++ ...
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?
I'll whack a --follow option into rpmdeps, not hard.
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.
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 ...
If you want Requires: name.arch implemented, please add comments at https://lists.dulug.duke.edu/pipermail/rpm-devel/2007-May/002505.html
Added in rpm cvs, will be in rpm-4.4.9-0.5 when built. UPSTREAM
*** Bug 234446 has been marked as a duplicate of this bug. ***
*** Bug 212523 has been marked as a duplicate of this bug. ***
*** Bug 203080 has been marked as a duplicate of this bug. ***
*** Bug 216025 has been marked as a duplicate of this bug. ***
User pnasrat's account has been closed
Reassigning to owner after bugzilla made a mess, sorry about the noise...
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.
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
Ain't going to be fixed in F9, moving back to rawhide...
New rpm implementing what's described in comment #19 is in rawhide now...
(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?
See http://rpm.org/wiki/PackagerDocs/ArchDependencies