Bug 212524 - RFE: xxx-devel.arch should require xxx.arch not just xxx
RFE: xxx-devel.arch should require xxx.arch not just xxx
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Depends On:
  Show dependency treegraph
Reported: 2006-10-27 04:26 EDT by Hans de Goede
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version: 4.4.2-35
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-11-12 06:14:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Hans de Goede 2006-10-27 04:26:21 EDT
When I install libXt-devel.i386 I expect it to drag in libXt.i386 and
not to be happy with the already installed libXt.x86_64 .

This requires (AFAIK) an enhancement to rpm to bne able to specify the arch of a
Requires in the spec file.


This will also stop some polution with i386 packages of x86_64 system,
because currently we have the following scenario:

libXt-1.0.2-3.fc6.x86_64 is installed

Users does "yum install libXt-devel.x86_64"

Yum finds libXt-devel-1.0.2-3.1.fc6.x86_64,
which needs libXt-1.0.2-3.1.fc6.x86_64 yum does decides to update the
x86_64 version of libXt and as an added bonus also install the i386
version since both match the requirement of libXt-devel-1.0.2-3.1.fc6.x86_64
Comment 1 Jeff Johnson 2006-10-27 10:51:11 EDT
Yum chooses the packages that are added to a transaction set, rpm does what is specified.
Comment 2 Hans de Goede 2006-10-27 10:57:37 EDT
The error / problem lies at the rpm level. If I install foo.x86_64.rpm and then
foo-devel.i386.rpm both directly with rpm from the cmdline then rpm is happy,
and IMHO it shouldn't be happy, as I now have a symlink in called
/usr/lib/libfoo.so pointing to the non existen /usr/lib/libfoo.so.0
Comment 3 Jeff Johnson 2006-10-27 11:12:23 EDT
Yep. I'd say you need to invoke rpm -i correctly, that would certainly "work" if you
chose to do that.

The underlying problem is that rpmlib is about mechanism, not policy. While your
expectations are perfectly sound, attempting a policy choice within rpmlib forces
everyone to live with that policy, which usually leaves some user unhappy.

E.g. see #171970 for an example of what happens when rpmlib starts attempting
to implement policy rather than pure mechanism. The policy that #171970 is running
into is
    No transaction shall contain identically named packages, the newer pkg will bused, the
    older will be discarded.

It's far easier to just choose the correct pkgs to install than to attempt policy within rpmlib imho.
Comment 4 Jeff Johnson 2006-10-27 11:24:55 EDT
FWIW, (assuming that foo-devel*.i386.rpm is one of the majority of -devel
packages that contain a libfoo.so symlink), rpm-4.4.7 would have detected
the dangling symlink and failed to install.

IMHO, there is little that is not objective mechanism implementing
    Every symlink shall require its end-point (i.e. no dangtling symlinks permitted).
while attempting policy based on intuitive concepts like "x86_64" (why not "amd64" or "ia32e" or ...?)
and "-devel" (does the -devel package contain a symlink to a library?) are not the right approach.
Comment 5 Jeff Johnson 2006-10-27 12:33:07 EDT
Need I say it? (I do have to say it because I use the UPSTREAM marker to identify those bugs
that I believe are already fixed in rpm even if not Fedora).

Comment 6 Hans de Goede 2006-11-12 06:14:47 EST
It turns out that this has already been fixed in FC-6 rpm, closing.
Comment 7 Jeff Johnson 2007-04-11 08:14:12 EDT
Please add comments to


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