Subject: Re: NetBSD 2.0 release date
To: John Franklin <franklin@elfie.org>
From: Jason Thorpe <thorpej@wasabisystems.com>
List: tech-kern
Date: 12/08/2003 09:03:01
--Apple-Mail-15-253984697
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed


On Dec 8, 2003, at 8:42 AM, John Franklin wrote:

> On Dec 7, 2003, at 3:06 PM, Jason Thorpe wrote:
>> Version checks will not solve the problem.  Sigh, I guess I'll have 
>> to repeat the crux of the problem *again*.
>>
>> Consider this:
>>
>> 	program foo depends on libc.13 and libother.0
>>
>> 	libother.0 depends on libc.12
>>
>> *EVEN IF* you have 100% complete inter-library version consistency 
>> checking, you still lose in this situation.  What if foo and libother 
>> both call function zap(), and zap() is one of the things that had an 
>> ABI change between the two libc versions?
>
> How would this program even link?  Wouldn't the linker return a storm 
> of duplicate symbols as it tries to resolve through both versions of 
> libc?

What if program foo was compiled on a different host, and you received 
it as a binary?  What if, on that other hose, libother.0 had a recorded 
dependency on libc.13 (i.e. it is a "fresh install"), but you are 
running it on a host that has an older libother.0 that has the libc.12 
dependency.

This is a totally normal, acceptable situation that should work 
(assuming the library minor numbers are the same).

Now let's say libother is a 3rd-party library, which is used on many 
different operating systems.  How easy do you think it will be to get 
the libother maintainers to bump their shared library version?  How 
easy do you think it will be to maintain a local patch for all eternity 
that keeps the shared library version ahead +1 of the stock libother 
version (and only for specific versions of NetBSD)?

How easy do you think it will be to maintain such patches for hundreds 
(or even thousands) of 3rd-party libraries?

         -- Jason R. Thorpe <thorpej@wasabisystems.com>


--Apple-Mail-15-253984697
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQE/1K7FOpVKkaBm8XkRAtveAJwMdLIAF6jRRbpPFwsPPTb3Lzb1VQCfXm7z
5ZvJoZMxVkrrPIZgKrkuy5c=
=J867
-----END PGP SIGNATURE-----

--Apple-Mail-15-253984697--