Re: glibc 2.1 broke a couple of things.
> >
> > Glibc 2 and 2.1 can not co-exist. There is a little known version of Debian
> > called `stable' that some people doing real work use, you might find it
> > useful. Unstable is often, well, how do I put it, a bit unstable, and hence
> > not good for doing real work.
>
> Sigh ... That's fine and I know about stable. And if I had
> abundant hardware, I'd have one machine running stable and one machine
> running unstable and everything would be happy.
> However, I don't, and I try to help in the development and debug
> effort, but need to keep the same machines in a happy working condition so
> that they can still be usable to do real work.
> If the machines on which debian were to be tested on were not used
> for real work, how well debugged do you think they'd end up being? Debian
> would end up being a toy distribution if that were the case (this isn't a
> flame. This is a point of fact).
>
> What are the technical reasons for not being able to keep a glibc
> 2.1 and glibc 2.0 library on the same system? How was it done with libc5?
>
> I do consider it a bug that upgrading to glibc2.1 do not give any
> warning about packages that it broke and that there is not a viable
> downgrade path.
When potato is released, this wont happen. You are "upgrading" to the middle
of the process. libc5 and libc6 were very different beasts, glibc2.1 is a new
version of 2.0. It has a similar soname so it mistakes libc6 for 2.1.
The library implementation is changed. Hopefully less problems due to sonames
in the future. Once all the kinks are worked out, potato will be an easy
update like normal.
The easy answer is not update machines for the next week or three while Debian
catches itself up.
Reply to: