From owner-svn-src-stable@FreeBSD.ORG Tue Apr 2 21:08:06 2013 Return-Path: Delivered-To: svn-src-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 09615E7D; Tue, 2 Apr 2013 21:08:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id D928FAB8; Tue, 2 Apr 2013 21:08:05 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2CEBAB943; Tue, 2 Apr 2013 17:08:05 -0400 (EDT) From: John Baldwin To: Brooks Davis Subject: Re: svn commit: r248352 - in stable/9: etc share/mk Date: Tue, 2 Apr 2013 15:50:43 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201303152132.r2FLWfwx076672@svn.freebsd.org> <201303200918.08803.jhb@freebsd.org> <20130402175903.GA85393@lor.one-eyed-alien.net> In-Reply-To: <20130402175903.GA85393@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201304021550.43701.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 02 Apr 2013 17:08:05 -0400 (EDT) Cc: svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Dmitry Morozovsky , svn-src-stable-9@freebsd.org X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 21:08:06 -0000 On Tuesday, April 02, 2013 1:59:03 pm Brooks Davis wrote: > On Wed, Mar 20, 2013 at 09:18:08AM -0400, John Baldwin wrote: > > On Tuesday, March 19, 2013 4:06:31 pm Brooks Davis wrote: > > > On Tue, Mar 19, 2013 at 09:49:47PM +0400, Dmitry Morozovsky wrote: > > > > On Tue, 19 Mar 2013, Brooks Davis wrote: > > > > > > > > > > > Replace all known uses of ln in the build process with appropriate > > > > > > > install -l invocations via new INSTALL_LINK and INSTALL_SYMLINK > > > > > > > variables. > > > > > > > > > > > > It seems this merge breaks ``make distribution'' and hence mergemaster if your > > > > > > base system is not updated yet (for example, while updating jail): > > > > > > > > > > Sorry for the delay in responding. I missed this yesterday. > > > > > > > > > > It works for me on a older 9.0-STABLE system where the base install > > > > > doesn't support -l. Did you build world or run "make toolchain" in that > > > > > source tree to build the bootstrap copy of install? > > > > > > > > Yes, this is after full ``make buildworld buildkernel'' process. > > > > > > I've found the problem thanks to misc/177055. It is that mergemaster > > > (and etcupdate) set MAKEOBJDIRPREFIX to something in their > > > temporary directory and thus deprive themselves of bootstrap tools. > > > Unfortunately, I don't see a trivial fix so I've backed this out for > > > now and will work on this in HEAD. > > > > Hummmm. In the case of etcupdate you can use 'etcupdate -B'. That is actually safe > > to do in the common case where you've just updated /usr/src and built the corresponding > > world in /usr/obj. It should possibly even by the default for etcupdate if a DESTDIR > > is not specified. > > Finally getting back to this... > > etcupdate -B would correct the immediate problem for etcupdate. I do > think that making it the default if the tree exists makes sense. It > won't be more broken than a cross installworld is. Hmmm, checking for the obj tree is a bit hackish. I'd rather it were more deterministic. I think I'd like to make it just default to -B and require a new -b flag to build a new tree, but perhaps have it check for a tree and error out if it doesn't exist and you don't give it -b? > I did a quick test when I first found this issue and it would be easy to > reuse the existing MAKEOBJDIRPREFIX in mergemaster as well. > > I think we'll want to update UPDATING to recommend that the > mergemaster -p stage (and the equivalent for etcupdate) be run using the > version in the source tree, not the installed one. I do wonder if it > would make sense for them to attempt to find and invoke that version so > simplify bootstrapping. Currently etcupdate doesn't implement something like -p. I need to add that as I would prefer to use its conflict resolution for adding users. (That would also let it serve as a full replacement for mergemaster for those who prefer it.) -- John Baldwin