On Thu, 21 Aug 2003, Hubert Feyrer wrote:

: > Hmm... I thought using DEPENDS directly included a single dependancy.
:
: You thought wrong. See bsd.*pkg.mk

Yup.  And, of course, the thread subject was changed since pkgviews doesn't
help this particular problem, except to provide a place to build new
versions of the whole gaggle of dependencies.  8-)

This is a well known deficiency of pkgsrc that has two prongs:

1. DEPENDS (which is recursively registered by bsd.pkg.mk); and

2. buildlink2.mk files (which recursively pull in other buildlink2.mk
   dependencies).

Fixing (1) is a prerequisite for fixing (2).

I suggested in PR pkg/21097 that (1) could be fixed Today with minor
breakage that can be fixed on a case-by-case basis.  This is because nearly
all large-dependency-list packages are already using buildlink2.mk for
dependency registration, and thus will still get recursive dependencies even
if DEPENDS is made non-recursive.  Note that there's a diff hack in that PR
that I've been using for a year now, setting PACKAGE_DEPENDS_RECURSE=false,
with no ill effect even though I'm using hundreds of things from pkgsrc and
installing via binary packages from a build box.

But fixing (2) is much more painful.  This will require splitting out the
DEPENDS part of each buildlink2.mk file somehow (via a new .mk file and/or a
make variable), so that other buildlink2.mk files can choose not to
propagate inner dependencies.  Manual inspection will then be required to
add these splits where appropriate; typically where one utility shlib has an
inner dependency on another utility shlib, but an application using the
first one doesn't care or know about the second.  For instance, GTK, SDL,
etc. abstract away their underlying implementation layers, so apps using
them don't give a damn about their dependencies.

-- 
-- Todd Vierling <tv@pobox.com>