Re: pkg/38272

[Gavan Fantom <gavan%coolfactor.org@localhost>]

The following reply was made to PR pkg/38272; it has been noted by GNATS.

From: Gavan Fantom <gavan%coolfactor.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: pkg/38272
Date: Mon, 24 Mar 2008 12:29:37 +0000

 Joerg suggested that we could second-guess where PKG_TOOLS_BIN was going 
 to end up. I had a play with that, and I can't come up with a way of 
 doing that which still leaves pkgsrc able to actually get as far as 
 building pkg_install.
 
 I have two possible approaches which I think could work.
 
 * A framework to re-invoke make with the current make target.
 
 This could be something generic, and used for bootstrap dependencies 
 which change something in the environment that requires reevaluation by 
 make. This would depend on make being aware of whether it was the 
 initial invocation of make in pkgsrc, and on being able to arbitrarily 
 exit, passing a message up to its parent that this reinvocation has been 
 requested. There's a lot of scary stuff surrounding the issue of running 
 two makes on the same source tree.
 
 * Declare that PKG_TOOLS_BIN shall never change.
 
 Decide on a One True Place for the tools to live on each platform. (This 
 is already done, save for NetBSD). On NetBSD, decide that the package 
 tools will *always* live in ${LOCALBASE}/sbin. Then, (very) early on, 
 make sure they exist. If they do not exist, look for 
 PKG_TOOLS_BIN_BOOTSTRAP and if present, make symlinks.
 
 This way, the pkg tools are always present, and always in the same 
 location. If the tools are sufficiently recent, they are merely accessed 
 via the symlinks. If they need upgrading, pkg_install will overwrite the 
 symlinks (make sure they are not followed in this step!) and pkgsrc will 
 immediately use the new tools.
 
 
 I am strongly leaning to the second option.