Subject: Re: Sleepycat Software DB 2.x library licensing vs. NetBSD
To: NetBSD-current Discussion List <current-users@netbsd.org>
From: Greg A. Woods <woods@most.weird.com>
List: current-users
Date: 09/19/1998 01:57:57
[ On , September 18, 1998 at 21:30:45 (-0700), Michael Graff wrote: ]
> Subject: Re: Sleepycat Software DB 2.x library licensing vs. NetBSD
>
> If the on-disk format changes between libc major version numbers, one
> libc will want to access, say, /etc/pwd.db with one DB format, and the
> new libc will want the new format.  This will break things, unless a
> fallback to parsing /etc/passwd is added in one of the cases.

Yup, you're right.  Yet another case where lumping non-dependent
components into one dynamic library is a *bad* idea.  (Before I jump off
into another deep end:  The NetBSD shared libraries will permit routines
in one dynamic library to call routines in another, won't it?)

So, can it still be done via a compatabilty library?  I *think* this is
just a S.M.O.P. to fix -- i.e. layer the DB 2.0 compatibility interface
into the compatability library in such a way that legacy applications
will in fact be accessing DB 2.x format files via the 2.x code in a
libdb2.so or whatever, and possibly even patch this compatability layer
into the old libc.so.

I say that I think this is possible to do as a wrapper layer, but of
course I've not actually tried to do it, so I can not guarantee it will
work.

One might also try to enhance DB 2.x so that it can read and write
old-format files, and people who must run ancient binaries can throw a
configuration variable on to keep things the way they were.

Ah, who cares about ABI backward compatability anyway?   :-)

(as a matter of fact I personally do not care about ABI backwards
compatability -- that's why I have the source, and I'm also not terribly
keen on shared libraries....)

-- 
							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>