Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 81277 - dependency on glibc not enforced, rpm can install non-functional /bin/rpm
Summary: dependency on glibc not enforced, rpm can install non-functional /bin/rpm
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: rpm
Version: 1.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2003-01-07 15:00 UTC by John Ellson
Modified: 2005-10-31 22:00 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-01-07 15:46:05 UTC

Attachments (Terms of Use)

Description John Ellson 2003-01-07 15:00:12 UTC
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/

Version-Release number of selected component (if applicable):

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
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:

Comment 1 Jeff Johnson 2003-01-07 15:16:51 UTC
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.

Comment 2 John Ellson 2003-01-07 15:34:44 UTC
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.

Comment 3 Jeff Johnson 2003-01-07 15:46:05 UTC
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

Comment 4 Michael Lee Yohe 2003-01-07 16:03:16 UTC
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.

Comment 5 Michael Lee Yohe 2003-01-07 16:04:36 UTC
It's nice when two people post simultaneously. :)

Comment 6 John Ellson 2003-01-07 16:40:02 UTC
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.


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