On Fri, 2 May 2003, Todd Vierling wrote:

> The way to fix this is not to bump PKGREVISION at will:  instead, it's
> necessary to have binary packages prefer a specific set of package versions
> and/or use a shared library lookup system (yes, this is where RPM has an
> advantage, and has been a known pkgsrc problem for a long time).

"pkg_add" currently prefers the dependencies a package was built
against, but that's a mess. You build a few packages, that you know
are backward compatible, on one machine, but then on the machines that
share the packages directory, you have to fight with "pkg_add" to get
the new packages installed, and of course, if you build your
collection by downloading packages, there are no guarantees.

I think the shared library thing is the way to go, since that is the
main issue that dependencies are trying to deal with. A good start
(Phase I) might be to add support for a couple of keys to
"libinstall": a "@needed" key, for the sonames need by the binaries,
and a "@version" key, so we'll know if no "@needed" keys means we
don't have any needs, or if it means that the package is old. The
PLIST already contains the information as to which sonames are
provided. (This embraces ELF, and ultimately means dropping support
for 1.5.3/*/a.out, but we're supposed to do that with the release of
NetBSD 2.0 in any case.)

Phase II would be to make pkgsrc responsible for stuffing the keys.
The mechanism is already there to run "ldd" over binaries (when
${PKG_DEVELOPER} is set), so that would just need to be extended a
little. We could easily be doing this by NetBSD 2.0. With this, it
would be possible to at least script the maintenance of the
collection, removing packages whose dependencies have been removed by
the vulnerability scan, and perhaps catch a few other gaffes.

While we're talking about removing packages, we should think about
removing the distfiles, too (but not until five years later, to comply
with the GPL for GPL'd packages, and for consistencies sake for the
non-GPL'd packages). To that end, I propose adding a "@distfile" key.

The final phase, Phase III, would be to extend "pkg_add" to do
something with the information, filling the dependency with the newest
package that meets the requirements. Even though the logic doesn't
sound too hairy, I still wouldn't like to tackle it until having a
sizeable, mixed collection in hand. Neither would it be useful until
that time. Ergo, we put that off until the last stage.

How about it?

Frederick