On Mon, Nov 19, 2007 at 02:47:35PM -0800, Min Sik Kim wrote:
> It is documented in the pkgsrc guide (Sec 18.4):
>
>   The USE_TOOLS definition is used both internally by pkgsrc and also for
>   individual packages to define what commands are needed for building a 
> package
>   (like BUILD_DEPENDS) or for later run-time of an installed packaged (such 
> as
>   DEPENDS). If the native system provides an adequate tool, then in many 
> cases, a
>   pkgsrc package will not be used.
>
> So USE_TOOLS is not a replacement for DEPENDS or BUILD_DEPENDS.

The above text contains an important requirement: "adequate". The
consensus for Perl was for a very long time that you almost always need
modules and defining a "reasonable" base version is non-trivial. E.g.
you end up with Perl if you want it or not. The above paragraph also
contains a "in many cases", explicitly hinting that exceptions are
possible.

Completely ignoring that, I also believe that USE_TOOLS provides a much
better syntax than DEPENDS and BUILD_DEPENDS does.

> Currently, some packages set USE_TOOLS when they need DEPENDS.  For 
> example, pkgtools/pkglint should not use USE_TOOLS+=perl, because it 
> requires pkgsrc perl with specific perl modules.  However, letting the 
> tools framework use native perl as a tool (as I did for Darwin) does not 
> break such packages; they already get dependency on pkgsrc perl implicitly 
> through the perl modules they depend on.

I am an opponent of hidden dependencies. Just because you depend on a
Perl module package doesn't mean the package itself is using Perl.
Another reason is patching for interpreters now has to distinguish
between "random perl" and "pkgsrc perl". Which one should it get? In
that sense the change does break the pkgsrc abstraction.

I don't exactly know what problem you want to fix. As I said, you are
highly likely to end up with Perl anyway, so it is only shuffling around
dependencies. If this was triggered by the Perl breakage -- it has to be
fixed ASAP anyway for the *same* reason.

Joerg