svn commit: r248352 - in stable/9: etc share/mk

[Brooks Davis]

On Tue, Apr 02, 2013 at 03:50:43PM -0400, John Baldwin wrote:
> 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?

Just switching the default seems fine in practice.  I guess it would
probably be useful to keep an option to enable the old behavior.

> > 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.)

OK, I'll look at switching the default behavior in mergemaster and
adding an option to revert to the old behavior.

I'll also change UPDATING to suggest using the mergemaster.sh from the
source tree for mergemaster -p.

- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20130402/c2b1a895/attachment.sig>