Subject: Re: use of IGNORE= for packages also incorporated into the system....
To: NetBSD Packages Technical Discussion List <tech-pkg@netbsd.org>
From: Greg A. Woods <woods@most.weird.com>
List: tech-pkg
Date: 02/25/1999 01:33:57
[ On Wednesday, February 24, 1999 at 08:56:21 (-0500), Todd Vierling wrote: ]
> Subject: Re: use of IGNORE= for packages also incorporated into the system....
>
> On Wed, 24 Feb 1999, Greg A. Woods wrote:
> :
> : Silly me -- I was assuming that pkgsrc would be branched at the same
> : time as the main source tree.  (That's why I explicitly said
> : "pkgsrc-current".)  Perhaps I'm dreaming too much about FreeBSD again....
> 
> Well, it has been considered, but probably won't happen, just because of the
> overhead of maintaining two pkgsrc trees.  Since the base OS's functionality
> doesn't phenomenally change from release to release, just a little version
> detection here and there makes pkgsrc work everywhere.

I'm actually extremely happy with the ability to use "pkgsrc-current" on
my -release machines, which is why I'm interested in being able to use
it as a quick (and perhaps not so elegant) way to install upgraded
versions of tools, including those that might already be integrated in
the base-OS.

At this point I don't really forsee any time when I would use a specific
release-branch of pkgsrc (nor do I see any reasons at this time that
there might even be circumstances where it might be recommended).  Of
course this does depend on the as-yet excellent support in pkgsrc for at
least the more recent releases (and the theoretical ability to support
even ancient releases).

Certainly it would be a tremendous effort to pull up pkgsrc changes to
release branches given the relatively long life of NetBSD release
branches (at least to date).  I wouldn't want to see valuable volunteer
resources squandered on such tasks, at least not until the NetBSD pkgsrc
surpasses other similar collections.

What irks me is that I will have to make manual changes to some pkgsrc
Makefiles in order to convince them to build and install their products.

I think there might be a better compromise to the quandry of installing
multiple versions of the same tools, or in particular of installing
executables in the package $PREFIX that are already included in the base
OS, than to hard-code checks for explicit filenames in the pkgsrc
Makefiles.  Perhaps an /etc/mk.conf variable could be made available to
override this "policy".

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