Bug 155356 - Dependencies on the package doesn't handle multilib
Dependencies on the package doesn't handle multilib
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: compat-gcc (Show other bugs)
ia64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Depends On:
  Show dependency treegraph
Reported: 2005-04-19 10:31 EDT by Trond Eivind Glomsrød
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-15 09:24:44 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 Trond Eivind Glomsrød 2005-04-19 10:31:03 EDT
compat-gcc-c++ depends on compat-libstdc++ = 7.3. Unfortunately, it doesn't
specify what arch... so you can uninstall the ia64 version, the compat-gcc-c++
package will still be happy.

The reason this is a major problem, is that compat-gcc-c++ "provides" some
libraries which are really found in compat-libstdc++ - and thus, compat-gcc-c++
can be selected as the solution for dependency resolving, without pulling in the
correct companion package.

[root@pe3250-1 root]# rpm -q --qf "%{NAME} %{ARCH}\n" compat-libstdc++
compat-libstdc++ i386
compat-libstdc++ ia64
compat-gcc-c++ ia64
[root@pe3250-1 root]# rpm -q --requires compat-gcc-c++
compat-gcc = 7.3-2.96.128
compat-libstdc++ = 7.3
compat-libstdc++-devel = 7.3
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
[root@pe3250-1 root]# rpm -e compat-libstdc++.ia64
[root@pe3250-1 root]# rpm -q --provides compat-gcc-c++
compat-gcc-c++ = 7.3-2.96.128
[root@pe3250-1 root]#
Comment 2 Jakub Jelinek 2005-04-24 07:34:23 EDT
rpm doesn't support that.  One can manually add stuff like
Provides: foo(%{_target_cpu}) and Requires: foo(%{_target_cpu}) etc., but then,
why should compat-libstdc++/compat-gcc be any special?  There are dozens if
not hundreds packages where similar problem can arise.
The current state of things is that up2date/yum/apt or whatever other dependency
solver should make sure appropriate arches of packages are installed.
Comment 3 Trond Eivind Glomsrød 2005-04-25 04:08:27 EDT
The reason this needs special treatment, is that compat-gcc-c++ provides these
libraries in a fake manner. Thus, it fools yum/up2date etc (which was why I ran
into this and submitted it in the first place).

The scenario is that compat-gcc-c++ and compat-libstdc++ for i386 is installed
on x86_64/ia64. compat-gcc-c++ for the native arch will the be happy that
compat-libstdc++ exists on the system, as it "fakes" that it provides the actual
binary libraries.

Without the fake libraries (which is another way to solve the problem, override
findrequires so it doesn't pretend to provide libraries it doesn't need), it
would work. But with the fake libraries, and not depending on compat-libstdc++
being of the proper arch, everything is good in dependency land, but not in the
real world Which makes certain thirdparty software (either Dell or Intel, I
don't remember) install cleanly, but fail when running.

Comment 4 Jakub Jelinek 2006-03-15 09:24:44 EST
This is fixed in RHEL4 and not severe enough to fix in RHEL3.

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