Subject: Re: src/gnu/usr.bin/egcs/common
To: NetBSD Userlevel Technical Discussion List <tech-userlevel@netbsd.org>
From: Greg A. Woods <woods@most.weird.com>
List: tech-userlevel
Date: 12/18/1999 18:35:21
[ On Saturday, December 18, 1999 at 13:54:36 (-0800), Greywolf wrote: ]
> Subject: Re: src/gnu/usr.bin/egcs/common
>
> On Fri, 17 Dec 1999, Greg A. Woods wrote:
> 
> # From what I can see problems don't occur until you start compiling
> # things again, and then only if you've got old third-party libraries
> # mixed into the fray.
> 
> So we're supposed to, what, hold out for five or six more releases before
> we decide to rebuild anything?

Oh, no, of course not!  These problems are far from unsolvable.  The
upgrade procedure should (or at least could) be modified to save away
all the necessary header files and library modules and a simple wrapper
on "cc" and "ld" or similar using the options I talked about would allow
one to continue to build programs that depend on binary-only libraries
that require the old system libraries.  Further there could be add-on
packages developed that provide a compatability environment for doing
such builds.  Making these changes would not be a trivial task, but it's
the sort of framework that will eventually be needed anyway if/when the
library major numbers really do have to be bumped.  The hardest thing to
do after getting all the old files squirrelled safely away where they
can be used might be fooling GNU Autoconf generated "configure" scripts
into only using the old library and headers.

The only time a brick wall might be built against the ongoing use of old
binary-only libraries is if any kernel syscall API the old libraries
(including the old libc) depend upon is removed/broken/etc.  Eventually
this will happen, but even then it may be possible to cobble up a fix,
provided that someone remembers how to rebuild the old library code
again.

>  I somehow don't think this is going to sit
> very well with most people (for example, I tend to rebuild fresh instances
> of packages for the version of the OS that I'm running!).

I'm not aware of any existing "pkg" packages that require third-party
binary-only shared libraries which depend upon our current libc shared
library, though of course I may be wrong as I've only actually used
about 25% or 30% of the pkgsrc collection (and have only built and used
135 binary packages).

Do you use some other third-party shared library, such as a commercial
Motif product?

If all your packages are source-only builds then you won't have any
worries at all, and provided you rebuild everything before you need to
use it, then you wouldn't even have to keep your old shared libraries.

> By the way, regarding backwards combatability, how long are we going to
> keep it?  There will be a point at which backward compatibilty with
> every 1.x release is going to become horribly inefficient (how many system
> calls are we going to keep around?).  I mean, don't get me wrong -- it's
> nice to have 1.2 stuff run under 1.4.1, but I can't see much point in
> hanging onto it _forever_.  That decision needs to be seriously considered
> before we get too far afield.

Very good question.

> I think that at this point if we upgrade the major version of the library,
> we will be forcing the door shut on ANY backward compatibility.   We may
> need to bite the bullet on that one, or we may need to find a way to
> strictly isolate the older version in a way that older programs will
> depend on it, and that newer programs cannot depend on it.

No, bumping the major version doesn't shut any door -- it just makes
life for some folks a little more complex.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>