svn commit: r261031 - in head: . etc usr.sbin/etcupdate usr.sbin/mergemaster

[John Baldwin]

On Thursday, January 23, 2014 5:48:34 pm Peter Wemm wrote:
> On 1/23/14, 2:12 PM, John Baldwin wrote:
> > 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 <gjb at FreeBSD.org> 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.)
> 
> FWIW, we do this at work and ran into the same problem.  We do the same
> things that poudriere does, almost exactly.
> 
> We added:  "CAP_MKDB_ENDIAN= PWD_MKDB_ENDIAN=" to the "make DESTDIR=/stage
> distribution" phase.  This currently works all the way back to stable/4.
> 
> Is there a middle ground where we could only specify -l / -b in a cross
> build perhaps?

I would be fine with that, definitely.  Not sure what the proper test
for that is though.

-- 
John Baldwin