From owner-freebsd-bugs@FreeBSD.ORG Thu May 15 14:10:18 2003 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E44DE37B401 for ; Thu, 15 May 2003 14:10:18 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BD3043F85 for ; Thu, 15 May 2003 14:10:18 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h4FLAIUp021620 for ; Thu, 15 May 2003 14:10:18 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h4FLAInh021619; Thu, 15 May 2003 14:10:18 -0700 (PDT) Date: Thu, 15 May 2003 14:10:18 -0700 (PDT) Message-Id: <200305152110.h4FLAInh021619@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Ruslan Ermilov Subject: Re: misc/52122: make release does not use proper binar X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Ruslan Ermilov List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2003 21:10:19 -0000 The following reply was made to PR misc/52122; it has been noted by GNATS. From: Ruslan Ermilov To: "David O'Brien" Cc: John Hay , bug-followup@freebsd.org Subject: Re: misc/52122: make release does not use proper binar Date: Fri, 16 May 2003 00:01:06 +0300 On Thu, May 15, 2003 at 11:31:40AM -0700, David O'Brien wrote: > On Thu, May 15, 2003 at 08:13:50PM +0200, John Hay wrote: > > On Thu, May 15, 2003 at 09:58:44AM -0700, David O'Brien wrote: > > > On Thu, May 15, 2003 at 06:31:42PM +0200, John Hay wrote: > > > > One reason why it isn't that useful inside the chroot area, is that > > > > if your running kernel and the newly built bits gets too much out of > > > > sync you will need to update the machine in any case, so you will > > > > end up with "new" binaries and a kernel on the machine and so it > > > > is a "waste" to recompile world inside the chroot area. > > > > > > In this case the release died near the end (release.9 target). It was > > > easy to update the running kernel and reboot. Now we wanted to restart > > > the release w/o starting from scratch. This release build included ports > > > README's and Docs, and thus takes a very long time to build. To not have > > > to start from scratch, I did "chroot ${CHROOT} /bin/sh" and then ran "rm > > > /tmp/.world_done ; /mk" which should have restarted the release build and > > > done the mimimum work to finish the release. It didn't because of the > > > cross-release commit that removed the installworld w/in the ${CHROOT}. > > > This bit not only me, but another person also building an Alpha snapshot. > > > > Maybe the issue is more of documentation? I know hindsight makes it easy, > > but an installworld inside the chroot area or "world DESTDIR=/chrootarea" > > should have been enough to get the binaries updated. > > It is, and was. The problem is restarting with /mk used to do this for > you. It stopped and the only documentation was hidding in the commit > log. > It used to, but only "if [ ! -f /tmp/.world_done ]", and you were way beyond that point, was it release.9? Nevertheless, I'm not going to repeat all arguments explaining why "make world" in CHROOTDIR is an etremely bad idea. In older days, it was necessary to ALWAYS upgrade to a recent before attempting to "make release". These requirements are now lifted, and it's often that you can build a fresh snap on an older system. Cheers, -- Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age