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 libc.so.6(GLIBC_2.3.4). 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 machine and: mkdir /tmp/glibc-fix cd /tmp/glibc-fix 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.4), libc.so.6(regexec.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 packages. 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.