misc/52122: make release does not use proper binar

Ruslan Ermilov ru at freebsd.org
Thu May 15 22:20:11 PDT 2003


The following reply was made to PR misc/52122; it has been noted by GNATS.

From: Ruslan Ermilov <ru at freebsd.org>
To: "David O'Brien" <obrien at freebsd.org>
Cc: John Hay <jhay at icomtek.csir.co.za>, bug-followup at freebsd.org
Subject: Re: misc/52122: make release does not use proper binar
Date: Fri, 16 May 2003 08:17:43 +0300

 On Thu, May 15, 2003 at 06:12:27PM -0700, David O'Brien wrote:
 > On Fri, May 16, 2003 at 12:01:06AM +0300, Ruslan Ermilov wrote:
 > > > > > 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?
 > 
 > Yes as stated clearly above, it was release.9 -- the very last release
 > target.
 > 
 > > In older days, it was necessary to ALWAYS upgrade to a recent
 > > before attempting to "make release".
 > 
 > So?  JKH and msmith at WCCDROM liked it that way.  Such issues as this
 > came up in discussions when I worked there.
 > 
 So to always be on the safe side for native builds, you should follow
 that old rule too -- this will guarantee that you will use fresh bits.
 
 The rule is simple: the fresh world SHOULD be able to release itself;
 the world other than the one that you're trying to release COULD be
 able to release, with a reasonable chance of working.  If you're not
 sure, upgrade kernel/world first.
 
 On Mon, Mar 17, 2003 at 07:00:56PM +0200, Ruslan Ermilov wrote:
 > Murray,
 >
 > Just wonder, what environment do you use to produce these
 > snapshots/releases.  Do you use the old canonical way of
 > first upgrading the building system to the level of the
 > snapshot/release, or do you just use the "compatible"
 > system like 4.7-STABLE?
 
 On Mon, Mar 17, 2003 at 09:17:40AM -0800, Murray Stokely wrote:
 > On Mon, Mar 17, 2003 at 07:00:56PM +0200, Ruslan Ermilov wrote:
 > > Just wonder, what environment do you use to produce these
 > > snapshots/releases.  Do you use the old canonical way of
 >
 > The build machines are running 4.8-RC and 4.8-PRERELEASE.  They aren't
 > running exactly the same level of the snapshot/release, but within 2
 > weeks or so.
 
 On Mon, Mar 17, 2003 at 09:26:35AM -0800, Murray Stokely wrote:
 > On Mon, Mar 17, 2003 at 07:20:30PM +0200, Ruslan Ermilov wrote:
 > > Great!  :-)
 > >
 > > And what environment you're planning to use to roll the final
 > > 4.8-RELEASE, when it comes to this point?
 >
 > It will probably be 4.8-RELEASE or within just a few days of that.  Of
 > course, if you're asking this because you want to make a disruptive
 > change, then that might affect what I'm able to use. ;) Why?
 
 
 Cheers,
 -- 
 Ruslan Ermilov		Sysadmin and DBA,
 ru at sunbay.com		Sunbay Software AG,
 ru at 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


More information about the freebsd-bugs mailing list