On Sun, 4 Feb 2001, Greg A. Woods wrote:

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

YES, it was a bug, for exactly this reason. Fortunately, this was
fixed between NetBSD-1.4.2 and NetBSD-1.4.3/NetBSD-1.5, so there
should be no binary packages on ftp.netbsd.org with this problem.

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

At the very least, we should read the configure script and turn off
everything that has a --no-this --no-that option. That goes a long
way, but it still often fails to catch dependencies on shared
libraries that are in most linux base distributions, like "readline".

> >   - if a package has any dependency, make it depend against a package
> >     which is the lowest version in compatible packages

Or how about build a baseline against the tag, then only update
packages as a group whose version numbers differ from the baseline
versions (so as not to overwrite the baseline packages). I'm working
on a set of scripts to help do this. I have most of the engine done --
a script to pluck the dependencies from pkgsrc, and another (a
four-pass awk script) to massage them into groups, but I'm still
struggling with how the command line options should look.

How would that help? At any given time, all the oldest packages in the
collection would remain a consistent set, and also all the newest
packages would remain a consistent set.

Even better, would be to create a tool to index the collection, and
use that index to negotiate a sane upgrade path. There's one missing
piece of information in the binary packages, though, and that is
exactly which dependencies they were built against. With this
information, "pkg_add" could balk at trying to substitute an _older_
dependency than the one the package was built against. Such would be
less than perfect in your eyes, Greg, but it would resolve many of the
common problems with binary packages.

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

Bring on the virgins. Donations to TNF are tax deductable.

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

Some folks are working on doing chroot builds. This, of course, solves
the "hidden dependency" problem without requiring more machines.


Frederick