Re: glibc 2.1 broke a couple of things.
On Sat, 13 Mar, 1999, Seth M. Landsman wrote:
> > 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).
Some more facts:
* It was well known that the move from glibc 2 to 2.1 would be hard. I am
supprised it is out of experimentaly, I am not going to upgrade until it has
settled down a bit.
* Java is non-free software, unsupported by Debian. It is yet another
demostration of the advantages of free software over non-free.
I wonder how the other non-free binary-only software like Netscape 4, and
Quake 2 will handle with glibc 2.1
* Software that is complied against glibc 2 and is written properly, does not
have a problem running with glibc 2.1 it is because JDK is using libc
internels that have changed with glibc 2.1 that it is broken. Java is badly
coded.
But of course you know all of that.
>
> 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?
It was a complete hack to get libc5 and libc6 running on the same machine.
The dynamic linker ldso was fixed so it would `do the right thing', e.g. make
an educated guess about which library to use. Granted it almost always gets it
right, but it is still a hack.
> 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.
It tend to agree there. I wonder how many other packages have this problem? Is
dpkg downgradable? Could I take potato and downgrade to rex?
--
GNU does not eliminate all the world's problems, only some of them.
-- The GNU Manifesto
Reply to: