Bug 81277 - dependency on glibc not enforced, rpm can install non-functional /bin/rpm
dependency on glibc not enforced, rpm can install non-functional /bin/rpm
Status: CLOSED WONTFIX
Product: Red Hat Raw Hide
Classification: Retired
Component: rpm (Show other bugs)
1.0
All Linux
high Severity high
: ---
: ---
Assigned To: Jeff Johnson
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-01-07 10:00 EST by John Ellson
Modified: 2005-10-31 17:00 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-01-07 10:46:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Ellson 2003-01-07 10:00:12 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):
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:
Comment 1 Jeff Johnson 2003-01-07 10:16:51 EST
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 10:34:44 EST
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 10:46:05 EST
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  
Comment 4 Michael Lee Yohe 2003-01-07 11:03:16 EST
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 11:04:36 EST
It's nice when two people post simultaneously. :)
Comment 6 John Ellson 2003-01-07 11:40:02 EST
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.

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