Subject: Re: pkg dependencies bite
To: NetBSD Packages Technical Discussion List <tech-pkg@NetBSD.ORG>
From: Greg A. Woods <email@example.com>
Date: 02/05/2001 14:37:57
[ On Monday, February 5, 2001 at 08:30:01 (+0900), firstname.lastname@example.org 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
> 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
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 <email@example.com> <robohack!woods>
Planix, Inc. <firstname.lastname@example.org>; Secrets of the Weird <email@example.com>