Red Hat Bugzilla – Bug 141063
Using CVS snapshots for glibc RPMs screws up package dependencies.
Last modified: 2007-11-30 17:10:55 EST
I have glibc 2.3.3-74 installed. This package is built not from glibc
2.3.3, but from some CVS snapshot taken after 2.3.3 was released.
Being a CVS snapshot, it includes some GLIBC_2.3.4 symbols.
Thus, the glibc RPM lists itself as providing libc.so.6(GLIBC_2.3.4)
However, because this is only a post-2.3.3 CVS snapshot and not an
actual glibc 2.3.4 release, it does not include all of the GLIBC_2.3.4
symbols that will be included in the final glibc 2.3.4 release.
Thus, the glibc RPM lies when it lists itself as providing
Therefore, it becomes possible for me to install packages that depend
on symbols found only in the forthcoming glibc 2.3.4 while still only
having glibc 2.3.3 installed.
That's bad. Extremely bad if one of those packages happens to be rpm
or openssh-server or something else critical.
In case you're wondering what brought this on, a guy in the #fedora
IRC channel upgraded libselinux on a remotely administrated FC3t2 box
to the libselinux that came with FC3 final.
His version of glibc didn't have __fprintf_chk(GLIBC_2.3.4), which the
libselinux RPM from FC3 requires, but because it had other GLIBC_2.3.4
symbols, RPM happily did the upgrade.
Because lots of critical stuff depends on libselinux, including RPM
itself, his system is now extremely broken.
Of course, you could say that Fedora Core test releases are even less
supported than regular Fedora Core release and ignore this issue, but:
1) RPM should always be able to do the right thing, and the use of CVS
snapshots in glibc subverts this.
2) I can see this potentially happening with RHEL systems and some
combination of glibc errata packages and other errata packages.
I ran into this too but didnt file a bug. The work around in my case
with a terminal still open on the dead box was to get on another
rpm2cpio glibc-2.3.3-84.i386.rpm | cpio -iv --create-directories
tar -czvf /tmp/glibc-fixes *
Then ftp from the dead machine, get the tar file and then dump it
locally. I just dumped it on / and rpm worked but this was just a laptop.
If you cant do something along these lines, I imagine you will need to
boot from a rescue CD.
To fix this rpm would need to have per symbol provides/requires, so instead
of requiring say libc.so.6(GLIBC_2.3.4), it would need to require
libc.so.6(__fprintf_chk@GLIBC_2.3.4), libc.so.6(regexec@GLIBC_2.3.4) etc.
But per symbol provides/requires would really blow up dependency resolution
or at least make it orders of magnitured slower.
But not introducing any new symbol versions, especially in Fedora Core test
releases, is not feasible either, that would inhibit any new development
on the glibc side.
Fortunately, missing symbol/version pairs are detected very well at package run
time, so application just won't start with a message instead of producing silently wrong results.
Just live with the fact that you need to upgrade glibc together with other packages. So in this case upgrade to FC3 glibc if you start using FC3 packages
on pre-FC3 system, rawhide glibc if you start using rawhide packages, etc.
Nothing stops you from doing glibc development, just stop using snapshots in
If you really really really need to use something that's in CVS in a package,
then make a new glibc release.
Presumably things will either be a) not important enough to warrant a new glibc
release, and thus not important enough to package in an RPM, or b) so important
that they need their very own glibc point release, and can be safely stuck in a RPM.