Subject: Usage of USE_TOOLS (was: Re: CVS commit: pkgsrc/mk/tools)
To: None <tech-pkg@NetBSD.org>
From: Min Sik Kim <minskim@netbsd.org>
List: tech-pkg
Date: 11/19/2007 14:47:35
(Moved from pkgsrc-changes@)

On Nov 18, 2007, at 3:55 PM, Masao Uebayashi wrote:

>>> Please back this out. USE_TOOLS+= perl is the canonical way to  
>>> depend on
>>> Perl and this breaks dependency handling completely.
>>
>> Then I am afraid we are abusing the tools framework.  We shouldn't
>> assume that the tools framework adds dependencies on pkgsrc packages;
>> it may select native packages instead.
>
> I'd want to clarify this point too.
>
> If USE_TOOLS is what Min means here, it should be always
> BUILD_DEPENDS, I think.  Is this correct?

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.

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've fixed wrong assumptions that USE_TOOLS+=perl brings in pkgsrc  
perl, and now it seems that both packages depending on pkgsrc perl and  
packages using perl as a tool build fine on Darwin.  But there was an  
objection to these changes on pkgsrc-changes@.

  - http://mail-index.NetBSD.org/pkgsrc-changes/2007/11/16/0026.html
  - http://mail-index.NetBSD.org/pkgsrc-changes/2007/11/19/0026.html

I don't think using native perl as a tool will break existing  
packages.  Native perl will be used only when a "perl" interpreter is  
all the package needs.  Other packages using additional perl modules  
will still use pkgsrc perl.  We are already doing the same thing for  
many interpreters including Tcl, Tk, and shells.

Should we make perl an exception in the tools framework?

Regards,
Min