Subject: Re: "make replace package" broken again
To: Todd Vierling <firstname.lastname@example.org>
From: Johnny C. Lam <email@example.com>
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)
> _REPLACEMODE= # set
> 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
-- Johnny Lam <firstname.lastname@example.org>