Date: Tue, 13 Jun 2006 08:48:21 -0400 From: John Baldwin <jhb@freebsd.org> To: "Greg 'groggy' Lehey" <grog@freebsd.org> Cc: Tom Rhodes <trhodes@freebsd.org>, src-committers@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org Subject: Re: HISTORICAL_MAKE_WORLD (was: cvs commit: src Makefile README) Message-ID: <200606130848.22261.jhb@freebsd.org> In-Reply-To: <20060612233752.GH79172@wantadilla.lemis.com> References: <200606070333.k573XmRc067920@repoman.freebsd.org> <200606120849.57695.jhb@freebsd.org> <20060612233752.GH79172@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >=20 > 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. >=20 > 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. >=20 > 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). =2D-=20 John Baldwin <jhb@FreeBSD.org> =A0<>< =A0http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =A0=3D =A0http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200606130848.22261.jhb>