On Fri, 15 Oct 2004, Julio M. Merino Vidal wrote:

> > This will hopefully encourage folks to reduce the amount of unnecessary bl3
> > recursion that is rampant in pkgsrc, making many packages "depend" directly
> > on APIs they never see nor use.
>
> Humm... but bl3 takes care of that already.  Dependencies pulled in from the
> buildlink3.mk files are treated as indirect ones; many still have to be
> included from the buildlink3.mk files to make sure that required header/library
> files (either directly or indirectly) are present in the buildlink directory.

Well, BUIILDLINK_DEPTH eliminates the @pkgdep that happens to be encoded
into downstream dependencies.  That's one step, but not a full decoupling of
recursive dependencies.

glib, imlib, imlib2 -- these are packages with a wealth of dependencies,
which don't change their outward ABI even in the case of one of their
dependencies changing.  But, thanks to the recursive bl3 includions, they
are pulling in the unused include/lib files of their dependencies.  And when
I went to alter a dependency of imlib2, which I'm fairly certain is not
exposed to imlib2's downstream dependents, I had to bump all the downstream
dependents' PKGREVISIONs anyway.

Currently, the only way to ensure that a PKGREVISION bump is done properly
for an ABI change is to trace through the chain of bl3 includes.  Or, put
another way, you have to bump PKGREVISION of anything that could _possibly_
depend on the ABI of a package whose includes/libs were exposed.  If that is
a tightly bound chain like it is today, always including the same bl3s as in
the Makefile, a low-level bump can mean bumping a lot of downstream
dependents that may not *truly* require a bump.

SDL also used to be quite bad with this, until it was modularized.  The fact
that the external modules' dependencies weren't actually needed by
downstream dependents of SDL should demonstrate this concept:  programs
using SDL never cared about the headers/libs of esound or arts, for
instance.  When the modules were factored out, so were the (already)
unnecessary bl3 inclusions in SDL/buildlink3.mk.

With all that said, I'm open to reverting this change, but it would be nice
if we could somehow keep this consideration in mind.  Abstraction APIs
become more common every day, and if we can eliminate the potential for
"explosive" PKGREVISION bumps, that would help reduce a lot of update
headaches....

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