Bug 141063
| Summary: | Using CVS snapshots for glibc RPMs screws up package dependencies. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Nicholas Miell <nmiell> |
| Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-11-29 07:04:02 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Nicholas Miell
2004-11-29 01:08:20 UTC
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. |