Re: glibc 2.1 broke a couple of things.
> > 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.
That's fine. In hindsight, I shouldn't have upgraded. I do have
a problem with the lack of downgrade path. I wish there was a way to
migrate over to the new glibc. I also wish there were some big, nasty
warning flags around it.
> * 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
Oh yeah, I forget, I'm not allowed to run non-free software. I'll
take my lab and go to redhat. That's an *AWFUL* reason. Saying "well
it's nonfree and therefore if it breaks, it is your problem for using
java, even though there isn't a working free version" and generalizing
that to all non-free software is going to do more to kill free software
than all the non-free software in the world.
Free software only works when it is a viable alternative. So long
as it isn't a viable alternative, evangalizing it over non-free won't
work.
> * 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.
And there is a lot of software that is compiled like that. Going
in with the aim of breaking software that doesn't meet those real high
standards doesn't make them meet those standards, it only shrinks the pool
of available software.
> But of course you know all of that.
Yes. I knew all that. I don't agree with it.
> > 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.
What about LD_LIBRARY stuff? Won't that work?
> > 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?
Gee, I remember the last major breakage I had (undefined symbols
in dselect, I think), it was possible to downgrade dpkg. I'm not
generalizing my statements, I wish you wouldn't do the same. When a
library is introduced that has potential to seriously break things, being
able to unbreak them tends to be important. I had to do my first
reinstall of a linux system last night. I consider that a bug.
-Seth
--
"It is by will alone I set my mind in motion"
Reply to: