| Summary: | ERROR with rpm_check_debug vs depsolve | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | mertensb |
| Component: | yum | Assignee: | Packaging Maintenance Team <packaging-team-maint> |
| Status: | CLOSED WONTFIX | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 5.8 | CC: | seth.alford, zpavlas |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-04-04 14:27:16 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
mertensb
2011-11-09 16:07:08 UTC
I just saw depsolve versus rpm_check_debug issue with CentOS 5.5, when trying to install 32 and 64 bit ImageMagick rpms and its 32 and 64 bit dependent rpmss. The rpm_check_debug vs depsolve failed, complaining about missing 64 bit packages. The above bug looks somewhat similar to what I saw, so I thought I would post a comment. Here's some of the complaints I saw:
Running rpm_check_debug
ERROR with rpm_check_debug vs depsolve:
libgnomevfs-2.so.0 is needed by libgsf-1.14.1-6.1.i386
libgdk-x11-2.0.so.0()(64bit) is needed by gnome-keyring-0.6.0-1.fc6.x86_64
libgdk_pixbuf-2.0.so.0()(64bit) is needed by gnome-keyring-0.6.0-1.fc6.x86_64
libgtk-x11-2.0.so.0()(64bit) is needed by gnome-keyring-0.6.0-1.fc6.x86_64
libgdk-x11-2.0.so.0()(64bit) is needed by libnotify-0.4.2-6.el5.x86_64
libgdk_pixbuf-2.0.so.0()(64bit) is needed by libnotify-0.4.2-6.el5.x86_64
....
My problem was intermittent. When I rebooted the system, the problem went away. However since I did not want to add yet another reboot to my upgrade process for the servers I work with, I spent some time looking at the problem, going through the yum libraries, and reading what I could of the Python code.
I discovered that my system had both 32 and 64 bit versions of rpm, rpm-libs, and rpm-build. Removing the 32 bit versions of these seems to have fixed my problem. What I think was happening is that yum thought it was installing both 32 and 64 bit versions of a set of packages. It told rpm to install them, through the rpm library interface. The 32 bit rpm library did not think it needed to install 64 bit rpms. So it skipped them. During the depsolve vs rpm_check_debug, the software discovered that the needed 64 bit rpms it wanted to install were not going to install. So the whole yum install failed.
Additionally, I saw a problem when I tried to install just one of the "leaf" dependents, libcroco, which did not have any additional dependents. yum reported that it successfully installed 32 and 64 bit libcroco. But, when I did
rpm -q --queryformat "%{NAME} %{ARCH}\n" libcroco
rpm only reported that the 32 bit (i386) package was installed.
To determine if both the 32 and 64 bit rpm, rpm-libs, and rpm-build packages are installed, I did:
rpm -q --queryformat "%{NAME} %{ARCH}\n" rpm rpm-libs rpm-build
This is probably a bug in Yum depsolver, which does not handle upgrade of openssl.x86_64 properly. Seems there was a soname bump, and Yum didn't recheck requires. Please enable and refresh repository your python, openladp et al packages are comming from, as these must be upgraded in the same transaction as openssl. |