On Fri, Dec 10, 2004 at 01:11:22AM -0500, John Klos wrote:
> Yes, I agree that it should happen in that order for all packages (is 
> there anyone who doesn't hate it when an already removed package doesn't 
> compile, then we're stuck scrambling to get something in place for the 
> users?)

	yeah, this is one reason why I've taken to building new packages in
a completely separate chroot environment.  (Well, actually multiple chroot
environments with a handfull of null and union mounts to get things to
show up in the right places.)  Combined with noticing that "bulk" build seem
to work better when building dependencies, that approach has actually
made things _so_ much easier to deal with.

> Everything works, with the exception of "make update" not cleaning after 
> itself when it's done.
	cool!

> "make replace" gives me:
> ...
> ===> do-su-replace [pkg_install-20041110] ===> Replacing 
> pkg_install-20041110
> *** WARNING - experimental target - data loss may be experienced ***
> No /usr/local/bin/pkg_tarup binary - can't pkg_tarup pkg_install
> ...

	and of course you need pkg_install to install pkg_tarup... nice
chicken and egg problem. :(

> For reference, this is a pretty virgin 2.0 install with the latest pkgsrc.
> For simplicity's sake, I had just added this to the Makefile to make 
> things work "normally":
> 
> NO_PKG_REGISTER=        # defined

	yes that works, but it has the unfortunate drawback that a binary
package of pkg_install can't be created, thus making it more difficult 
than necessary to update a machine w/o pkgsrc sources installed.  
	As I understand it, the original reason for that flag was to
keep packages from being deleted.  The better replacement for doing that
is the PKG_PRESERVE flag.  As you discovered, it still has a few quirks
to be ironed out. :)

eric