Red Hat Bugzilla – Bug 81277
dependency on glibc not enforced, rpm can install non-functional /bin/rpm
Last modified: 2005-10-31 17:00:50 EST
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):
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
/bin/rpm non-functional, complains about some library symbol in GLIBC.
/bin/rpm should be conservatively safe and stable, or perhaps there
should be a /bin/rpmsafe for use in emergencies like this.
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.
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
config(rpm) = 4.2-0.49
popt = 1.8
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(VersionedDependencies) <= 3.0.3-1
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.