On Nov 21, 2007, at 1:06 PM, Joerg Sonnenberger wrote:

> On Wed, Nov 21, 2007 at 12:48:52PM -0800, Min Sik Kim wrote:
>>> 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.
>
> No, it can also be read as "a pkgsrc package will always be used". In
> fact, that is the case for at least Perl and intltool. Haven't checked
> other cases.

Yes, intltool requires pkgsrc perl, and so does pkglint.  And such  
packages must use DEPENDS.  USE_TOOLS should be used only when the  
package does not care whether the tool comes from pkgsrc or the native  
system as far as it is "adequate".

If setting USE_TOOLS means "a pkgsrc package will always be used" for  
*some* packages, and "either pkgsrc or native" for others, how pkgsrc  
developers are supposed to know which packages fall into the former  
and which the latter?  To avoid ambiguity, it is better to say that  
USE_TOOLS always means "either pkgsrc or native" and that DEPENDS  
means "always pkgsrc".  (We will need more types of dependencies then  
these two as Roland pointed out earlier in this thread.)

> This is the very same situation as having builtin.mk or not. It  
> doesn't
> make sense to do that all time and it can create a lot of problems  
> to do
> so. That's why it is not done for random libraries.

Agreed.  That's why we don't use builtin.mk at all in such cases.  The  
tools framework is like builtin.mk in that it determines whether a  
native package is adequate or not.  If we want a pkgsrc package, we  
must not use the tools framework.

Regards,
Min