Re: Slink to potato upgrade
>>>>> On 23 Mar 1999 14:06:22 GMT, Roland Rosenfeld <roland@spinnaker.de> said:
Roland> Kevin Dalley <kevin@seti-inst.edu> wrote:
>> Whether the application is written "correctly" or not, if the
>> application has enough users, and was supported, however
>> inadvertently, under the old libraries, users will have problems
>> with the libraries. Moral superiority doesn't fix the user's
>> broken software.
Roland> True words.
>> First we should make a decision as to whether glibc2.1 *should* be
>> a separate soname.
Roland> I don't think so, unless other distributions or the upstream
Roland> maintainers do this, too.
>> If so, then we should talk to the rest of the Linux community and
>> decide how to resolve the issue.
>> You seem to prefer a sounding dichotomy:
>> 1. Break many users code when they upgrade to potato.
Roland> A worse solution. When I upgrade from one library to a newer
Roland> one with the same soname, this should not break any programs
Roland> which worked with the old library.
It should not break any well written programs. The contract is with
the public API not what you can get away with. If the programs don't
use the public API then they have broken the contract and breaking
them is perfectly acceptable.
Roland> If this isn't possible with glibc 2.1, this library is simply
Roland> broken and should be fixed (either by the upstream author or
Roland> by the Debian maintainer). Telling me that this is the
Roland> problem of the applications which break, is worse style
Roland> IMHO. A library with the same soname and a bigger version
Roland> number has to be 100% compatible to the prior one and if
Roland> there were some "internal functions" which were used before
Roland> and which are no longer available, then the new library has
Roland> to implement these functions for backward compatibility until
Roland> the soname changes.
No. A library does not have to implement internal interfaces that
once were public and now are not. Those interfaces should never have
been used. Any code that does must be fixed, but it is NOT the fault
of the library that programs were broken and just happened to work
with the old library.
>> 2. Create binary incompatibility with other Linux distributions.
>> Neither of these options is good.
Roland> Fully agree.
Roland> So we IMHO have the choice between the following two ways:
Roland> 3. Fix the problems in glibc 2.1 and make it fully
Roland> compatible to glibc 2.0 like the soname says (optimal
Roland> solution, but maybe not trivial to realize for the
Roland> glibc-maintainers).
No.
Roland> 4. Create a glibc2.0 "oldlibs" package which automatically
Roland> installs when glibc 2.1 is installed and which
Roland> automatically creates wrappers for all programs the break
Roland> with glibc 2.1 (is there a list of these
Roland> programs/packages available?). This should work in a way
Roland> similar to xaw-wrappers.
Why? These programs will be fixed in the next few weeks. Why put so
much effort into something that will be thrown away shortly? That
said I don't see any problems with some industrious person doing
this. Are you offering?
Roland> 5. Step back to glibc 2.0 until either 3. or 4. are
Roland> realized.
Another bad idea. This is UNSTABLE. Get used to breakage or stop
using it.
>> If Debian were the only distribution to use new sonames, that
>> would be an area for criticism. However, if no distribution uses
>> new sonames, and many applications fail, Linux as a whole will be
>> mocked be users and non-users. Moral superiority is
>> fine. Usability is essential.
Roland> That's the point.
Last I checked slink is perfectly usable and potato is mostly so. If
you want something that has less breakage go back and use slink. This
whole argument is getting tiresome.
If you don't want to help debug debian then don't use unstable, but
you sure as hell shouldn't complain when a _few_ things break in
debian's attempt to make a better distribution.
Dres
--
@James LewisMoss <dres@ioa.com> | Blessed Be!
@ http://www.ioa.com/~dres | Linux is kewl!
@"Argue for your limitations and sure enough, they're yours." Bach
Reply to: