HISTORICAL_MAKE_WORLD (was: cvs commit: src Makefile README)

[John Baldwin]

On Monday 12 June 2006 19:37, Greg 'groggy' Lehey wrote:
> On Monday, 12 June 2006 at  8:49:56 -0400, John Baldwin wrote:
> > On Friday 09 June 2006 20:57, Greg 'groggy' Lehey wrote:
> >> On Friday,  9 June 2006 at  8:53:47 -0400, John Baldwin wrote:
> >>> On Wednesday 07 June 2006 20:48, Greg 'groggy' Lehey wrote:
> >> Obfuscation is always wrong.
> >
> > Not in this case.
> 
> There's only one value of "always.  Obfuscation is always wrong.

Your use of "always" here is wrong.  Look, the fact that 'make world'
still exists is a compromise.  It should be removed altogether, but as
a compromise when that was brought up it was only allowed to work if
one either specified a DESTDIR (as it can still be useful for
cross-building the world for a netbooted box) or the undocumented knob.
That was the _intentional_ nature of the compromise agreed to at least
a year or so ago.  Go archive-diving if you don't believe that.  At
this point I'd actually say we just axe HISTORICAL_MAKE_WORLD altogether
and just always bomb if DESTDIR isn't set.

> >>>> The only justification for this regression is that it's really
> >>>> difficult to get everything right.
> >>
> >> Otherwise people would have fixed it.
> >
> > No, you aren't reading what I'm saying.
> 
> In fact, it's the other way round.  You're not understanding what *I*
> am saying.  The real issue here is distinguishing between a feature
> and bug that is difficult to fix.

Makefiles don't reboot machines and control which kernel gets booted
along with the AI to handle the case that something breaks!  That's
not in make(1)'s problem domain at all.

> > The justification is a _fundamental_ _design_ FLAW in how 'make
> > world' works.  You can't just patch around that.  You can't force
> > 'make world' to boot up a new kernel for you that will work with the
> > new userland you are about to install.
> 
> Why not?  This is in fact pretty much what System V does in a slightly
> different situation.  It's not done well, but as I said, it's
> difficult.

Then how about this.  Until you submit a patch to "fix" 'make world' to
actually work, it is going to stay obfuscated since it's current
implementation is unsafe and we don't want our users unnecessarily
trashing their machines.  If you can make a patch for /usr/src/Makefile
that safely reboots the machine into a new test kernel and then does
the installworld in single user mode then go for it.  Oh, and it needs to
handle all of the non-automatable stuff about booting kernels that we
normally rely on a human to handle for OS upgrades (like if the new
kernel fails to boot).

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org