Bug#167409: glibc 2.3.1: breaks XEmacs builds; system breaks on revert to 2.2.5
>>>>> "Daniel" == Daniel Jacobowitz <dan@debian.org> writes:
Daniel> You're talking about _forward_ compatibility. If we're
OK.
Daniel> going to preserve forward compatibility, we might as well
Daniel> stop developing the library. It is absolutely impossible
Daniel> to add new functions, change the size of data structures,
Daniel> change semantics, etc. without breaking forward
Daniel> compatibility.
Of course it's not, for the limited use I have in mind. ld -static is
your friend. Mine, anyway. I'd gladly sacrifice the 75MB it would
take to static-link everything in /bin and /sbin to the gods of
forward compatibility.
Daniel> There are some packages in the archive whose dependencies
Daniel> don't reflect this properly right now. [...] We've fixed
Daniel> it and packages will eventually be rebuilt.
Good. I don't have any complaints about glibc, you know (well, the
400kB overhead for a static build in non-trivial programs that makes
ld -static mostly impractical, but that's something else again). It's
the Debian dependency database that screwed me, not glibc. Not to
mention the carelessness that the first packages released were built
against the incompatible version of glibc were system-critical.
Debian's glibc package isn't quite as good as upstream glibc on
backward compatibility, either. Cf libdb1-compat. That one cost me a
few hours, too (codafs passes around binary databases, dumb, but not
easily fixable, and the Debian libdb1 package was broken---had to
build from source).
Daniel> The error message is precisely accurate. The rebuilt tar
I'm sorry, I meant my quotation was inaccurate, not that tar didn't
require glibc 2.3.
Daniel> binary _REQUIRES_ glibc 2.3. If you downgrade it by hand
Daniel> it's your own neck on the line.
I'm aware of that. I didn't do this on my main system, you can bet.
What pisses me off is that the only way I know of to get the
transitive closure of packages that downgrading glibc will break is
dpkg -i without --force-depends, and it screwed me by attempting to
downgrade glibc. It cost most of two hours to get that system back
into service.
Do you know of a better way? I've tried "-i --no-act" in the past,
but that doesn't work right---it never tells you about the dependency
issues. And I _needed_ a glibc 2.2.5 Debian system; it was the only
way to be sure that the change that caused unexec to break was the
glibc upgrade.
Right now the lack of command-line dependency analysis tools is my
main complaint against Debian as a system.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Economics of Information Communication and Computation Systems
Experimental Economics, Microeconomic Theory, Game Theory
Reply to: