> 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.)