Subject: Re: "make replace package" broken again
To: Todd Vierling <>
From: Johnny C. Lam <>
List: tech-pkg
Date: 07/06/2006 10:25:40
Todd Vierling wrote:
> Maybe "make replace" shouldn't use the common barrier, but rather be
> its own isolated target?  It is rather Special compared to plain
> "install", so it can't really participate in the normal
> chain-of-targets logic.

Yes, I kind of just threw "replace" in there to make it work in the 
isolated case of "make replace" that I knew someone else used.

> As it is right now, "make replace package" tries to do an "install"
> rather than a "replace":
> =====
> /usr/pkgsrc/pkgtools/pkglint $ nice make replace package clean
> [...]
> ===> patch-message [pkglint-4.66] ===> Patching for pkglint-4.66
> ===> configure-message [pkglint-4.66] ===> Configuring for pkglint-4.66
> ===> install-message [pkglint-4.66] ===> Installing for pkglint-4.66
> => Becoming ``root'' to make su-install-all (/usr/pkg/bin/sudo)
> =====
> To keep from horking up the existing nonrecursive line of logic, we
> could instead do something like:
> .if make(replace)
> .endif
> replace: install
> This would set a variable to tell pkgsrc that we're "installing in
> replace mode", which is what "replace" actually does, then defer right
> back to the plain "install" target.

I wonder if we should just have a REPLACE_TARGET, similar to 
UPDATE_TARGET, which is the target to invoke when installing the 
package.  It would default to "install" but in your case, you would do:

	make replace REPLACE_TARGET=package

There's another idea I want to try first which would try to synthesis a 
better command line to use when invoking the barrier's recursive make. 
Basically, instead of checking for the presence of a single target at a 
time, we check for all "post-barrier" targets and pass them all to the 
recursive make.


	-- Johnny Lam <>