[ On Monday, February 5, 2001 at 08:30:01 (+0900), itojun@iijlab.net wrote: ]
> Subject: Re: pkg dependencies bite
>
> 
> 	in general, yes that's true.  the real source of the problem is 
> 	that you have two set of openssl files in your system.

that should never be a problem in an ideal world -- I should be able to
have *every* version of OpenSSL installed simultaneously if I have
enough disk space to contain it all; and with an ideal package-build
system I should be able to choose which version to use with which
package(s); or I should be able to default to using the system-supplied
version, if it is present.

> 	the best solution i can ever think of is to remove pkg-based openssl
> 	when you get openssl in base tree (like upgrade to 1.5).  it is safe
> 	to keep pkg-based openssl for a while (until next time you compile
> 	new binary), but if you keep two of them longer and run compilation,
> 	you will be in trouble.

Keeping a pkg-based openssl installed would be fine, but there are those
hidden and unregistered dependencies from other packages so changing the
pkg-based openssl, or removing it, does cause immediate and in the case
of removal, fatal, problems for all of those dependent packages that are
linked dynamically.

> 	there are other reasons to add -L/usr/pkg/lib -I/usr/pkg/include
> 	(like for ncurses), and if you have /usr/lib/libcrypto.so and
> 	/usr/pkg/lib/libcrypto.so, you have no idea which one will be picked.

With package builds the ideal solution is to *NEVER* use -L but instead
to only give explicit library names on the linker command-line and to
use -I only with very extreme care (i.e. never point it to a place where
there are multiple different things installed, but only ever point it to
one unique directory per dependent package, eg. use the very explicit
"-I/usr/pkg/include/openssl-0.9.5").

Unfortunately the unix build model tends to take the approach of using
what's there instead of requiring explicit dependencies.  This was a
fine approach when all the world's stable except for the particular
program you're building, but when everything can change on a moment's
notice it just does not work.  I.e. it's fine if you never use any '-L'
or '-I' options that point at add-on packages of any kind.

> 	also, if you use /usr/pkg/include/openssl with /usr/lib/libcrypto.so,
> 	you will be in a BIG trouble.

That's exaclty the problem all right.  You can't assume that just
because the library has the same name that it implements the same API.
If add-on libraries and header files were always installed in unique
locations that explicitly identified their version numbers then you'd
have only two choices:  use the default system supplied libraries and
headers if available; or choose an explicit add-on version by specifying
its library files exactly (without -L) and specifying its include files
with something like "-I/prefix/package-pkg.ver.sion/include".

Unfortunately reaching this degree of control over package builds will
require a lot more work and some funamental changes to the way packages,
especially those which provide development tools, are installed.

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