Re: Basic replace support for DESTDIR

[Greg Troxel <gdt%ir.bbn.com@localhost>]

> I always end up doing pkg_add -u manually, as I always use DESTDIR
> support.  A very simple yet non-elegant workaround would be to create
> the new packages in a seperate directory; then the user could move
> them back as desired.  I know that I'd much rather have *some* way of
> using pkg_rolling-replace with destdir support even if it's not
> complete.

I agree - I think 'make replace' is critically important functionality,
and it would be nice to get destdir builds working with it.  Using the
pkg_tarup phase from the regular make replace will save the old package,
and pkg_add -u really is the same (or should) be as the source-based
make replace save/deinstall/install/restore phase.

Probably pkg_add -u needs to be spiffed up to handle the per-package
variable semantics of make replace, but this should happen anyway - I
haven't gotten to it.  Basically, preserve most variables, including
'automatic', and unset unsafe_depends and unsafe_depends_strict.

> I realize that the general idea is not to add
> incomplete/buggy features to pkgsrc, but, on the other hand, we still
> have MAKE_JOBS--and that is _inherently_ broken and _cannot_ be fixed,
> whereas this feature could always be improved.

As far as I know MAKE_JOBS works fine.  The problem is that half the
upstream packages are buggy (yes, this is a statement about my view on
modern requirements).  So if MAKE_JOBS_SAFE defaulted to no and was set
to yes in makefiles, it would be fine.  (Given where we are, with a lot
of packages marked, I don't think we should change.  I routinely rebuild
everything I use with MAKE_JOBS=4 on a 2-cpu machine and have trouble
less and less often.)