Re: Slink to potato upgrade
Robert Woodcock <rcw@debian.org> writes:
> On Tue, Mar 23, 1999 at 11:41:52AM +0000, Kevin Dalley wrote:
> > First we should make a decision as to whether glibc2.1 *should* be a
> > separate soname. If so, then we should talk to the rest of the Linux
> > community and decide how to resolve the issue.
>
> This is not our decision to make. It is the decision of the upstream
n> authors (the decision that influenced their entire 2.1 development path),
> and they have very clearly decided that for us.
>
> You have shown no respect for their decision.
I have respect for the source code the developers have produced. It
appears to be a very good implementation of the C library. However,
upgrading shared libraries is a very tricky problem. These libraries
must work with programs the library developers have never seen. The
decisions should be made by a bigger group of people than just the
library develeopers. There is a balancing act. We must provide our
users with tools which work for them, while providing a conforming
implementation.
We don't want our users to upgrade to stable potato and say:
Oh shit, my program has stopped working. It won't even
compile. I need to get my work done now, I don't have time to
fix the program until next month. I'm screwed. I should have
stayed with Microsoft.
Part of the reason there are problems with glibc2.1 is that the older
libraries didn't quite follow the GNU coding standards:
External symbols that are not documented entry points for the user
should have names beginning with `_'.
I believe that some external symbols lack the '_', allowing, maybe
even encouraging users to depend on insufficiently documented features.
> It's not "many" applications though. They can be counted on two hands, and
> that number will easily go down to one hand by the time potato is frozen.
> (It won't go down to 0 - some of the breakage is in things like staroffice
> that aren't packaged in debian)
The number can't be counted by us. We don't know what our users have
on their machines. We *cannot* fix the problem by fixing all of our
applications, because we can't fix our user's applications.
> It's not "many users code" either. It's only affecting people who don't play
> by the rules and use library interfaces that don't officially exist.
Please give a list of all of the rules which are violated. It isn't
only undocumented interfaces.
> I'm using glibc 2.1 right now. It works fine. If it was such a big deal, I
> wouldn't be able to type this to you.
glibc2.1 works fairly well, though I still have a number of broken
programs on my machine.
--
Kevin Dalley
SETI Institute
kevin@seti.org
Reply to: