Bug 212524

Summary: RFE: xxx-devel.arch should require xxx.arch not just xxx
Product: [Fedora] Fedora Reporter: Hans de Goede <hdegoede>
Component: rpmAssignee: Paul Nasrat <nobody+pnasrat>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 4.4.2-35 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-11-12 11:14:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Hans de Goede 2006-10-27 08:26:21 UTC
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 14:51:11 UTC
Yum chooses the packages that are added to a transaction set, rpm does what is specified.

Comment 2 Hans de Goede 2006-10-27 14:57:37 UTC
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 15:12:23 UTC
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 15:24:55 UTC
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 16:33:07 UTC
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).

UPSTREAM

Comment 6 Hans de Goede 2006-11-12 11:14:47 UTC
It turns out that this has already been fixed in FC-6 rpm, closing.


Comment 7 Jeff Johnson 2007-04-11 12:14:12 UTC
Please add comments to

    https://lists.dulug.duke.edu/pipermail/rpm-devel/2007-April/002260.html