Jeremy C. Reed writes:
 > Not really. I see that mk/tools/replace.mk checks if PKG_OPTIONS includes 
 > "cups" and it it does it uses ghostscript-esp. By default it uses 
 > ghostscript-gnu if a package needs a tool provided by a ghostscript 
 > (dvipdf, gs, pdf2ps or ps2pdf).

Yes, but the problem occurs in the following scenario.

1. Launch a leaf package that ultimately requires _some_ (i.e., any)
   ghostscript package.  In the absence of some global means of
   specifying which one, this dependency will be resolved by
   ghostscript-gnu.

2. Launch a build of cups (or a cups-depending package).  The
   previously installed ghostscript-gnu will not necessarily work
   correctly with cups or its dependencies.

Clearly, this introduces an order dependency in the build process,
which is error prone if you know about it and downright mysterious if
you don't.

This is only the example I am most familiar with.  It seems that when
the following conditions hold, there should be a means of globally
specifying how to resolve the dependency:

1.  More than one alternative package exists that can satisfy a
    general functional dependency, in this case the several
    ghostscript-* packages.

2.  That set of valid dependencies packages is not always identical
    for dependent packages, in this case the alternative packages
    dependent on ghostscript (some require only ghostscript-esp, some
    are broader).

Cheers,
Brook