[ On Sunday, February 21, 1999 at 21:13:36 (-0500), Todd Vierling wrote: ]
> Subject: Re: use of IGNORE= for packages also incorporated into the system....
>
> These happen primarily for the duplication factor; bulk pkgsrc builds should
> never include something shipped with the OS.
> 
> Whether written or not (and I may check up to find out if it is written
> down--if not, it will be), pkgsrc CANNOT install binaries in
> ${PREFIX}/{s,}bin with the same names as programs with the base system.  
> That's one of the pkgsrc prime directives.  This is done so that there's no
> $PATH dependency, period.  (Disputes to this policy will be dumped in
> /dev/null, as it has been discussed many times over.)

Well, if it's "policy"....  (I still think it's stilly and unnecessary,
even for the supposedly G.C.D. of naive users that pkgsrc is targeted
at, but....)

> The only real exception is the `cross' pkgs, which offer that as an option
> thanks to the difficulty of cross-ifying many build setups; the programs are
> not actually installed in ${PREFIX}/bin, but in an arch-specific
> subdirectory of ${CROSSBASE}.

Well, there's also pgtools/pkg_install, and possibly more, though I see
that pkg_install isn't included in the default top-level build.

Actually there's the hint I was looking for.

If something's pulled into NetBSD-current then it should simply be removed
from the default top-level build in pkgsrc-current -- there's no need to
hack the pkg to try and do special-case detection of base-OS functionality.

If someone wants to actually cd into the directory and build it by hand
then they should be allowed to do so.  There's clearly established
precedence for doing tool "upgrades" this way already.  A hint could
also be added to the pkg/DESCR file to warn people that they may be
creating a possible conflict because the tool is already in the base OS.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>