[ On Monday, January 22, 2001 at 10:50:54 (+0900), Masao Uebayashi wrote: ]
> Subject: Re: pkg dependencies bite
>

and "hidden" package dependencies bite the most and the hardest.

I'm now rebuilding the umpteenth package that had a stealth dependency
on the OpenSSL package on a -current machine with OpenSSL installed
natively because of the use of "-L${PREFIX}/lib" in package builds.  I
had encountered something at one point, probably due to a now fixed bug
in pkgsrc, that required the OpenSSL package instead of the in-tree
version.  I eventually cleaned up that mistake and deleted the OpenSSL
package.  Suddenly half my packages fail with ``Shared object
"libcrypto.so.1" not found''!  (this latest one is ethereal!)

If you let a package configure itself, especially one using GNU
Autoconf, it will find all kinds of wonderful things that you never
expected it to find.

> If "pkgsrc" tries to be responsible to binary compatibility, it seems
> better not to permit 'foo-1.0.2', which may be not binary-compatible.

Unless the pkgsrc module maintainers are willing to do full QA it's
almost certainly best to always use exactly what the package author
recommends.

> Just easy thoughts, but I can think of what should be done for
> "pkgsrc" to make binary packages more tolerant (and convinient for
> users) are:
> 
>   - verify compatibilities of binary packages _throughly_
>   - if a package has any dependency, make it depend against a package
>     which is the lowest version in compatible packages
>   - rewrite all 'pkg_*' tools... *duck*

One thing for sure -- binary packages should always be built on virgin
machines with only their known dependencies pre-installed (and
preferably pre-installed from the binary packages created for them!).
That's the only sure way to guarantee they never find and use any other
libraries or tools for which there's no dependency registered.

And then of course they need to be tested on a virgin machine too....

Maybe the bulk build mechanisms can be taught to do things this way....

Unfortunately doing this kind of thing while also providing support for
production environments pretty much doubles the number of machines (or
at least unique boot environments) necessary....

I may have to give up on using releases, or -current....   :-)

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