Subject: Re: ATTENTION: avoid using libc.13
To: Greg A. Woods <email@example.com>
From: Frank van der Linden <firstname.lastname@example.org>
Date: 10/21/1997 17:07:18
On Tue, Oct 21, 1997 at 10:16:06AM -0400, Greg A. Woods wrote:
> I think you may misunderstand what I mean.
> - undo the changes to stat(2) so that everything is as it was
> - bump libc to libc.so.14 (or rather 15, but that's a diff. issue)
> Nothing gets broken. Nobody has to jump through hoops. etc.
So, you ship 1.3 with libc.so.14. A first time user does a clean install
of 1.3, and then gets Xfree86. "ld.so: libc.so.12 not found". Oops.
"nothing gets broken?" I think not.
The only way to be completely backwards compatible is to provide all
major versions of shared libraries that ever existed. There are some
methods to make this problem less serious, like: give 3rd party
library vendors time to create new versions of their libraries,
so they can be provided with the new release. Or: if a major number
is bumped with a release, also provide the previous one, hoping that
no dependencies older than this exist. Note that bumping a major
number because of a changed interface effectively also requires you to
bump the major numbers of all the other shared libraries who
use this changed interface. So you'll end up providing numerous libs.
We really need to get a release out; bumping the major number at
this time was a mistake, and dealing with the above problems is not
something you want to do when you're in the process of finally getting
another release out. Sure, sometime you will have to increase the
major number, you can't depend on backward compat hacks forever.
This wasn't the right time to up the major number, it shouldn't have
been done in the first place. If the less painful way of solving
this is going back a major number (one that has only been used
for 2 days and by a small minority of users), then you just do
that. Also, it gives us time to contemplate and find a satisfactory
solution for the next time. Sure, it's not the most gracious
way to do it. But it was the least painful one, and it's not
the end of the world. Some people were inconvenienced; this
is unfortunate, but possible if you track -current. That sure
beats having a new release which has the problem described above
and thus scares away new users.
> > At this point, libc.so.13 was already broken. We needed the old
> > implementation to have the old name..
> I don't see why. The old implementation with an even newer name should
> suffice and if it doesn't then things are far more broken than I want to
> even contemplate.