From owner-cvs-all@FreeBSD.ORG Mon Jun 12 13:28:26 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 DCE2C16A41F; Mon, 12 Jun 2006 13:28:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F44F43D46; Mon, 12 Jun 2006 13:28:25 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from osx.baldwin.cx (osx.baldwin.cx [192.168.0.15]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k5CDSNV5012219; Mon, 12 Jun 2006 09:28:23 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Greg 'groggy' Lehey" Date: Mon, 12 Jun 2006 08:49:56 -0400 User-Agent: KMail/1.9.1 References: <200606070333.k573XmRc067920@repoman.freebsd.org> <200606090853.48604.jhb@freebsd.org> <20060610005707.GK7549@wantadilla.lemis.com> In-Reply-To: <20060610005707.GK7549@wantadilla.lemis.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606120849.57695.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Mon, 12 Jun 2006 09:28:24 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1534/Mon Jun 12 08:30:53 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Tom Rhodes , src-committers@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org Subject: Re: HISTORICAL_MAKE_WORLD (was: cvs commit: src Makefile README) 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: Mon, 12 Jun 2006 13:28:26 -0000 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: > >> On Wednesday, 7 June 2006 at 10:51:45 -0400, John Baldwin wrote: > >>> I thought the obfuscation was intentional as very few people should > >>> be doing a 'make world' without a custom DESTDIR these days. > >> > >> Then there's no reason not to document it. > >> > >> Warning: FORCE_ROOT_INSTALL can render your system unusable by > >> overwriting existing configuration files. Do not use it unless you > >> are completely aware of the consequences. > >> > >> And yes, a descriptive name like FORCE_ROOT_INSTALL, not > >> HISTORICAL_MAKE_WORLD. > > > > Describing it would subvert the intended obfuscation. > > s/subvert/correct/ > > Obfuscation is always wrong. Not in this case. > >> The only justification for this regression is that it's really > >> difficult to get everything right. But that's a bug, not a > >> feature. > > > > No, the justification is that 'make world' completely ignores the > > kernel and only handles userland, and an operating system is both a > > kernel and a userland and that users should update those together. > > That's a bug in make world. Introducing a second one doesn't fix it. The bug was fixed by the 'buildworld / buildkernel / installkernel / installworld' process that we now use. The bug is fundamental to the way that make world works and you can either change how make world works or you can require no ABI changes in the kernel <-> userland interface. We chose to change how make world works. > > If you as a developer want to use make world you can either run the > > two commands back to back or you can put > > I_REALLY_KNOW_WHAT_IM_DOING_AND_WANT_TO_HOSE_MY_MACHINE in make.conf > > or something. However, developers wanting to do this are in the > > _VAST_ minority and I'd much rather cater to the other 99% of the > > world. > > As I say, > > >> 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. 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. -- John Baldwin