Bug 155356
| Summary: | Dependencies on the package doesn't handle multilib | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Trond Eivind Glomsrød <trondeg> |
| Component: | compat-gcc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.0 | CC: | shillman |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | ia64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-03-15 14:24:44 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: | |||
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.
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. This is fixed in RHEL4 and not severe enough to fix in RHEL3. |
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-gcc-c++ 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 libc.so.6.1()(64bit) libc.so.6.1(GLIBC_2.2)(64bit) libc.so.6.1(GLIBC_2.3)(64bit) 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++ libstdc++-libc6.2-2.so.3()(64bit) libstdc++-libc6.2-2.so.3(GLIBCPP_2.96)(64bit) libstdc++-libc6.2-2.so.3(GLIBCPP_2.96_1)(64bit) libstdc++-libc6.2-2.so.3(GLIBC_2.2)(64bit) compat-gcc-c++ = 7.3-2.96.128 [root@pe3250-1 root]#