From owner-svn-src-all@FreeBSD.ORG Thu Jan 23 22:13:17 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57E50C2B; Thu, 23 Jan 2014 22:13:17 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2B57D1234; Thu, 23 Jan 2014 22:13:17 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0EBECB917; Thu, 23 Jan 2014 17:13:16 -0500 (EST) From: John Baldwin To: Bryan Drewery Subject: Re: svn commit: r261031 - in head: . etc usr.sbin/etcupdate usr.sbin/mergemaster Date: Thu, 23 Jan 2014 17:12:51 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <201401221659.s0MGxrc7056036@svn.freebsd.org> <201401231503.42671.jhb@freebsd.org> <20140123212256.GA37334@admin.xzibition.com> In-Reply-To: <20140123212256.GA37334@admin.xzibition.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201401231712.51610.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 23 Jan 2014 17:13:16 -0500 (EST) Cc: svn-src-head@freebsd.org, Glen Barber , svn-src-all@freebsd.org, src-committers@freebsd.org, David Chisnall X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 22:13:17 -0000 On Thursday, January 23, 2014 4:22:56 pm Bryan Drewery wrote: > On Thu, Jan 23, 2014 at 03:03:42PM -0500, John Baldwin wrote: > > On Thursday, January 23, 2014 2:48:41 pm Bryan Drewery wrote: > > > On Thu, Jan 23, 2014 at 02:39:14PM -0500, John Baldwin wrote: > > > > On Thursday, January 23, 2014 10:42:36 am David Chisnall wrote: > > > > > On 22 Jan 2014, at 22:36, Glen Barber wrote: > > > > > > > > > > > It needs to use the build host version, because using (for example) > > > > > > powerpc resulting binary won't work on and amd64 system. > > > > > > > > > > If it's used as part of the build, then it should be part of the toolchain > > > > target and we should be using the version built there. > > > > > > > > 'make distribute' is not a normal part of the build (it's not part of > > > > buildworld or installworld). Both mergemaster and etcupdate only run it > > > > after an installworld has been performed, in which case an up-to-date > > > > services_mkdb should already be installed. > > > > > > > > Bryan, what are you running 'make distribute' for? Is this to populate > > > > a new jail from a world build? > > > > > > Yes, poudriere uses this to create jails. It runs: > > > > > > export TARGET_ARCH=... > > > make buildworld > > > make installworld DESTDIR=... > > > make distrib-dirs DESTDIR=... DB_FROM_SRC=1 > > > make distribution DESTDIR=... > > > > > > > > > No mergemaster or etc-update is ran, we just install all of the > > > defaults. > > > > Yes, but you are attemping to install a newer jail than the host, and strictly > > speaking that isn't supported. (Rather, we only guarantee that a jail will work > > so long as its world is older or equal in age to the host.) > > I am aware of *running* newer jails not being suppored, but *building* > seems to be an absolute must to be supported. How else would you > upgrade? A normal upgrade does 'installworld' followed by some sort of /etc updating tool. It doesn't do 'make distribute'. Also, this is related to why one is not guaranteed to be able to do an 'installworld' unless you've booted into the new kernel first (though it often works, and 'make distribute' also often works, but often != always). The thing is, there is no notion of cross-tools, etc. for things like installworld and distribution. We have always expected the host to have ITOOLS that work. Note that this exact situation has happened before back when cap_mkdb and pwd_mkdb grew endianness flags for release cross-builds. The pwd_mkdb flag and the change to enable it in etc/Makefile were both made on the same day. (The cap_mkdb change was made earlier, but that appears to be more a result of the testing cycle for cross-building releases than an intentional delay.) -- John Baldwin