Red Hat Bugzilla – Bug 212524
RFE: xxx-devel.arch should require xxx.arch not just xxx
Last modified: 2007-11-30 17:11:46 EST
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
Yum chooses the packages that are added to a transaction set, rpm does what is specified.
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
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
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.
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.
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).
It turns out that this has already been fixed in FC-6 rpm, closing.
Please add comments to