Bug 81277
| Summary: | dependency on glibc not enforced, rpm can install non-functional /bin/rpm | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Raw Hide | Reporter: | John Ellson <john.ellson> |
| Component: | rpm | Assignee: | Jeff Johnson <jbj> |
| Status: | CLOSED WONTFIX | QA Contact: | Mike McLean <mikem> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 1.0 | CC: | michael |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2003-01-07 15:46:05 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: | |||
This is a glibc, not an rpm, problem. You have a version of rpm compiled against glibc-2.3.1-25, and are using glibc-2.3.1-30. No fix is possible until glibc stops changing, and then the problem will disappear. I disagree. If glibc is changing then rpm needs to be built against a stable glibc, not the unstable one. In any case, if the glibc dependency had been coded in the rpm it wouldn't have mattered that rpm had been built against a newer glibc. You can disagree all you want, but you're running on buggy, rapidly changing software that is still under development. If that's not to your taste, then please stop doing that. All necessary dependencies are already included in the rpm package: yarmouth:/X/src/rpm 278 bash$ rpm -q --requires rpm /bin/sh /bin/sh /bin/sh /bin/sh config(rpm) = 4.2-0.49 fileutils gawk libbz2.so.1 libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.2) libc.so.6(GLIBC_2.2.3) libc.so.6(GLIBC_2.3) libelf.so.1 libelf.so.1(ELFUTILS_1.0) libpopt.so.0 libpthread.so.0 libpthread.so.0(GLIBC_2.0) libpthread.so.0(GLIBC_2.2) librpm-4.2.so librpmbuild-4.2.so librpmdb-4.2.so librpmio-4.2.so librt.so.1 librt.so.1(GLIBC_2.1) mktemp popt = 1.8 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(VersionedDependencies) <= 3.0.3-1 shadow-utils textutils I think what Jeff is saying is that you are using a rawhide RPM - something that is considered "unstable" and "unfit" for general purpose use. It's for testing purposes and should be considered alpha or beta quality software. Until the glibc package is finalized - it would be too time consuming to regressively check all the rawhide RPMs based on sub-revisions of glibc packages. It's nice when two people post simultaneously. :) I accept that Rawhide is for testing. Thats what I was doing, and consequently reporting a problem. I wasn't complaining about the mess it made or asking for help getting out of it. Perhaps you're right and the problem is really that glibc made an incompatible change without incrementing its library version, but its still a problem. Even if the root cause is glibc, its still an rpm problem because rpm is churning at the same time and picked up the broken glibc. rpm needs more stability. Enough. |
Description of problem: /bin/rpm from rpm-4.2-0.50 has some dependency of a Pthreads symbol from glibc-2.3.1-30 (sorry, exact detail not recorded.) but the dependency is not enforced by the rpm-4.2-0.50.i386.rpm. If the user upgrades to rpm-4.2-0.50 before glibc-2.3.1-30 then /bin/rpm is non-functional and the user is stuck, unable even to backout the broken rpm package. (I recovered in the end by manually updating /lib/libpthread-0.10.so) Version-Release number of selected component (if applicable): rpm-4.2-0.50 glibc-2.3.1-30 How reproducible: Probably 100%, but I'm not going back there ;-) Steps to Reproduce: 1. upgrade rpm-4.2-0.50 before glibc-2.3.1-30 2. 3. Actual results: /bin/rpm non-functional, complains about some library symbol in GLIBC. Expected results: /bin/rpm should be conservatively safe and stable, or perhaps there should be a /bin/rpmsafe for use in emergencies like this. Additional info: