From owner-cvs-all@FreeBSD.ORG Tue Jun 13 16:50:46 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27B7016A484; Tue, 13 Jun 2006 16:50:46 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id B22DC43D92; Tue, 13 Jun 2006 16:50:45 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [IPv6:::1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k5DGmfkO023999; Tue, 13 Jun 2006 10:48:41 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 13 Jun 2006 10:48:41 -0600 (MDT) Message-Id: <20060613.104841.74726173.imp@bsdimp.com> To: jhb@FreeBSD.org From: Warner Losh In-Reply-To: <200606130848.22261.jhb@freebsd.org> References: <200606120849.57695.jhb@freebsd.org> <20060612233752.GH79172@wantadilla.lemis.com> <200606130848.22261.jhb@freebsd.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: grog@FreeBSD.org, trhodes@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, cvs-src@FreeBSD.org Subject: Re: HISTORICAL_MAKE_WORLD X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 16:50:46 -0000 From: John Baldwin Subject: Re: HISTORICAL_MAKE_WORLD (was: cvs commit: src Makefile README) Date: Tue, 13 Jun 2006 08:48:21 -0400 > 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. Time to cut the gordian knot: I plan on doing exactly this in one weeks time unless someone can give me a good reason not to it. It simplifies things, and provides just enough anti-foot-shooting ncessary for this case. It seems like a natural evolution of the thinking on this matter, and fits well with the compromise that was agreed to a while back. BTW, Good reasons do not include 'but make world should just work.' It doesn't work today. Until such time as it does, and we have the infrastructure in place to install a new kernel, and then run things early in the boot process once to do the installworld, make world will remain broken.... Such a mechanism could also be used for binary upgrades... But since no such mythical beast exists... Warner