Subject: Re: NetBSD 2.0 release date
To: NetBSD Kernel Technical Discussion List <tech-kern@NetBSD.ORG>
From: Greg A. Woods <woods@weird.com>
List: tech-kern
Date: 12/05/2003 18:57:24
[ On Thursday, December 4, 2003 at 17:00:00 (-0800), Bill Studenmund wrote: ]
> Subject: Re: NetBSD 2.0 release date
>
> I'm not sure. Bumping libc's version number will be a BIG BIG deal.

It's not really _that_ bit of a deal.  Certainly not in my opinion.  :-)
NetBSD is an open source system after all.  NetBSD doesn't _really_ need
to be anywhere nearly so single-minded about bass-ackwards compatability
as, say, Sun has been with Solaris.  I'm sure all NetBSD users can deal
with such a change without much grief, assuming they're made well aware
of what's happening.

Indeed if NetBSD can run foreign binaries, even symlinked ones, as
successfully as it does on as many different platforms as it does, then
treating NetBSD-(N-1).x releases as "foreign" emulations should be
relatively easy (though of course it probably should _not_ be done
through /emul unless we want to to change to a new ABI version too, and
maybe we do).

IIUC, if every system library gets bumped, as you say it needs to be,
then those upgrading need only retain the old library binaries from
their existing system and also of course use the appropriate COMPAT_*
options in their new kernels, until such time that they (or their
vendors) can recompile and re-install all of their production
applications.  If I'm not mistaken most of us already do such things on
a regular basis anyway, regardless of whether we need to or not!  :-)

> In the past, we've had packages in pkgsrc that supply the obsoleted 
> libraries. For a libc change, I think we'd actually need to supply them 
> ourselves, for at least a full release if not two. So that'd mean src/lib 
> would double (or more accurately it'd be cloned). I think we'd want syspkg 
> up to speed at that point too.

That's _way_ too much unnecessary work (IMO, of course).  There's no
need to recompile old libc code on new systems (and trying to do so,
especially with the attrocious way headers are used in system library
builds can only lead to even more horrid ugliness) -- just tell people
to keep their existing *.so files if they want to run old (shared)
binaries!  This practice has been good enough for Sun for much longer
than NetBSD has ever existed -- it should be good enough for NetBSD too.

(of course NetBSD may want to take another page out of Sun's book on
shared libraries too and give up on minor version numbers and only use
one level version numbers for shared libraries when this "bump" is
finally made....)

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>