Disabling dependency on esound in ports builds

[Conrad J. Sabatier]

On Fri, 20 May 2005 01:00:59 -0700, Ade Lovett <ade at freebsd.org> wrote:

> 
> On May 20, 2005, at 00:46 , Stijn Hoop wrote:
> > I do know the reason why this kind of code was added: it was
> > considered incorrect behaviour that port A would NOT automatically
> > pick up support for library B if it was installed by the user.
> 
> That's more an artefact of configure scripts especially being coded  
> to simply check for the mere existence of a library in order to use  
> it, instead of the more correct approach of explicitly requesting -- 
> enable-foo (or equivalent).
> 
> Bringing in all the necessary hacks to only activate extra code if  
> the user (or port Makefile) has explicitly requested it is (at best)  
> an awkward task.  It's considerably easier to give up and go with the 
> 
> exists() constructs which, as I've mentioned, do (in most cases) at  
> least register the dependency.
> 
> > [...] and considering reproducible package building
> 
> This right here hits the nail right on the head.  exists()  
> constructs, acting as the bandaids they are around poorly written  
> configuration scripts, can, and do, cause problems for building and  
> distributing packages in anything but an absolute virgin environment.

Well, in the case of GNOME and its constituent packages, it seems that
we have a case of automatic (indirect) dependencies run amok.  For
instance, just because a particular package may depend on, say, gtk2,
does that mean it should also automatically depend on a dozen or more
other components of GNOME as well, the majority of which will not be
employed in any way by the package?  I think not!

I just now did a "pkg_info -R esound-0.2.35_2", and was astonished to
see the number of packages listing esound as a dependency, even when
it's quite apparent that esound provides absolutely no additional
functionality to many of those packages.

I know we had quite a heated discussion some time ago in one of the
lists (or perhaps in comp.unix.bsd.freebsd.misc) on the subject of the
evils of indirect dependencies, but I don't recall any fruitful outcome
from it.

I really don't know what to suggest, or where such a discussion might
lead if we were to pursue it again, but it certainly does seem that
there's ample opportunity for some major cleaning up in the area of port
dependencies.  The current approach just seems rather heavy-handed, if
you ask me.  There should be some facility for a more fine-tuned
approach, leaning more in the direction of "when in doubt, leave it
out", rather than the current "throw it in just to be sure" methodology.

-- 
Conrad J. Sabatier <conrads at cox.net> -- "In Unix veritas"