[ On Monday, April 16, 2001 at 15:21:52 (-0400), Todd Vierling wrote: ]
> Subject: Re: pkg/12675: "bash" package can't be build on NetBSD 1.5 system
>
> However, the major number of libintl in the base system should probably be
> superbumped (to 10 or so) to make room for FSF expansion, to make the number
> larger than the one in /usr/pkg/lib.

In the past I've always thought that if the vendor used only even major
and minor numbers then there'd be lots of room for end users to muck
about creating their own shared libraries (which is rather critical for
binary-only proprietary systems).

You're probably right that bumping by 10 would help in the case where
there are two levels of vendor.

However I do really have to wonder about the use of any kind of
numbering scheme to identify API changes across multiple levels of
"vendors" in any non-proprietary "open-source" environment.  I would
think that in this case the "vendor" closest to the "end user" would
have the final say and that incrementing library version numbers by one
(or perhaps by two if the "end user" is to be considered as a
binary-only user) would be more than sufficient.  The only important
distinction to be made is the difference between this "closest vendor"
and any "OEM supplier" and to not leave any impression that the any
number of these end user vendors might share any binary compatibility
just because they use the same "OEM supplier" for some component.  The
best way to do that might be to always provide an emulation for even
similar systems.  Seems kinda heavy-weight, but then managing dynamic
library versioning, especially when there's not clear one single vendor
in control, is more or less a nightmare anyway.

It would also help if the pkgsrc system followed the advice of the
libtool manual and always always always bumped the shared library
version numbers *every* time *any* change is made in the library
release.  Never ever assume that any older binary (i.e. one linked
against a previous version of a librray) will be 100% compatible with a
newer release of the library.  If you're really lucky you can understand
the changes from one release to another in the library code and
increment only the appropriate major, minor, or patch number of the
shared library and thus follow the search rules implemented by
ld.[elf_]so for shared library versioning and forward compatability.

-- 
							Greg A. Woods

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