On Nov 21, 2007, at 9:31 AM, Joerg Sonnenberger wrote:

> 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.

Agreed.  And in such cases, we should use DEPENDS or BUILD_DEPENDS  
explicitly, not USE_TOOLS.  As the guide states, USE_TOOLS implies  
that "a pkgsrc package will not be used" in many cases.

> The above paragraph also
> contains a "in many cases", explicitly hinting that exceptions are
> possible.

I am not claiming that USE_TOOLS must use a native package; it may or  
may not.  The sentence you referred to means a pkgsrc package will be  
used in cases where native one is unavailable or inadequate.  So the  
package using USE_TOOLS must be prepared for both scenarios.   
Currently, many packages defining USE_TOOLS+=perl are not.  I don't  
understand what you meant by "exception".

>
> 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.

I don't like hidden dependencies, either.  That's why I proposed to  
introduce python-like application.mk to perl
(http://mail-index.NetBSD.org/tech-pkg/2007/11/20/0012.html).

>
> 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.

Sorry, I'm not following you here.  What abstraction is broken?  When  
a package sets USE_TOOLS, it expects a "random" tool, either from the  
native system or from pkgsrc.  Once the tools framework picks up an  
"adequate" one, the package should always use the chosen one.  In  
fact, allowing Perl to be an exception will break the abstraction  
introduced by the tools framework.

> 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.

I am trying to make the interpretation of USE_TOOLS consistent with  
what the guide defines.  Using native perl as a tool on Darwin  
revealed many inconsistent usages of USE_TOOLS, and I am fixing those,  
too.  Even if I am "highly likely to end up with Perl anyway", it is  
not an excuse for those inconsistent usages.  And there are many  
packages that need only a vanilla perl interpreter, so I am very  
likely to avoid pkgsrc Perl in such cases.

Regards,
Min