On Wed, 25 Mar 1998, Jonathan Stone wrote:

: I think you're saing we cant change major numbers, *ever*, or at least
: we get no benefit from it if we do.

: Shipping packages of old shlibs seems like a better scheme than
: growing libc.12 forever and ever and ever...

(Less ranty now, I promise:  it was that way just because I'd been building
up a counterargument for a while, just that no one really asked it.  ;)

No, I'm saying we need binary compatibility with the ability to get new libc
features.  Unlike, say, libutil, the features in libc can, and frequently
do, change in some way invisible to the API.  These changes could be
necessary for a more streamlined system integration (for example, nsswitch) 
or ability to use old binaries at all (for example, IPv6).

Whereas on Solaris the major of libc never changes, the major of other
libraries have changed.  In the case of libresolv, for example, the major
number bumped after a BIND API change, though the nsswitch DNS module
changed in an invisible way that didn't break libc.  Programs needing
internal functions of the resolver were supposed to break with the API
change, and they did.

Not that we should keep growing libc as is:  that's why I proposed a stub
library, possibly one that made use of the old shlib in /emul/netbsd or
somesuch and intercepted calls which had new functionality, or a stub
library that calls all functions in libc13.  It *is* possible to use ELF
shlibs on a.out binaries and shlibs in an upward fashion, and I have asked
for pointers to ELF information to attempt to figure out how to implement
it. 

-- 
-- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)