>> I understand why this is being said, but this is like saying all that
>> work to support DESTDIR in the source Makefiles is all for naught.
> 
> Hardly for naught.  I found it useful just recently, when making a
> crash-recovery boot disk.  I mounted the new disk and did a "make
> install" in my source tree with DESTDIR pointing to where I'd mounted
> the new disk.  Then I installed a kernel and bootblocks, and voila!

This, of course, presupposes that you have an entire successful build in
/usr/src to begin with in order to do this.  Can you say, "Catch-22"?  Sure ...
I knew you could ...

> It seems it doesn't do quite what you want, well, I agree with you that it
> would be nice to have what you want.  But I'm not prepared to call DESTDIR 
> useless because of that.

I didn't say it was useless, but it's currently an agonizingly-close-to-100%
(call it 98%) solution.  If <curses.h> properly got installed in the
beginning stages, and there were a way to build the -current gcc2 from the
existing 1.1 gcc 2.4.5 without it gagging on libgcc2.c, it would be at
least 99 44/100ths %.  Then one could build into $DESTDIR, see that everything
built correctly, and then either try some chroot'ed tests (as Phil Knaack
mentioned) or risk it all and boot from floppy, mount the disk(s) and tar up
$DESTDIR on top of the existing system.  If I have install a small part of
the -current system - especially something as vital as the *compiler* - to
get everything to go, then I see little point in trying to use DESTDIR.  If
I have to blow away something important, might as well blow it all away, eh?

In short, it seems a shame that such a nicely-implemented mechanism has to
trip over a source file or three when used for its presumably main purpose.

	- Greg