Re: Request for review/testing: switching the default installer

On Wednesday, March 02, 2011 10:36:58 am Nathan Whitehorn wrote:
> On 02/28/11 09:20, John Baldwin wrote:
> > On Monday, February 28, 2011 9:49:07 am Nathan Whitehorn wrote:
> >> BSDinstall has acquired at this point its final form (prior to a future
> >> merge with pc-sysinstall), and I believe is ready to replace sysinstall
> >> on the 9.0 snapshot ISOs. Barring any objections, I would like to pull
> >> this switch 2 weeks from today, on the 14th of March.
> >>
> >> A patch to the release infrastructure code can be found here (make
> >> release must be run with Makefile.bsdinstall using this patch to get
> >> non-sysinstall media):
> >> http://people.freebsd.org/~nwhitehorn/bsdinstall-release.diff
> > Hmm, does your installed world include the pre-built mergemaster database?
> > That should really be preserved.
> >
> > It happens here in the old release Makefile:
> >
> > # Install the system into the various distributions.
> > release.2:
> >          cd ${.CURDIR}/..&&  ${CROSSMAKE} distrib-dirs DESTDIR=${RD}/trees/base
> >          cd ${.CURDIR}/..&&  ${CROSSMAKE} ${WORLD_FLAGS} distributeworld \
> >              DISTDIR=${RD}/trees
> >          sh ${.CURDIR}/scripts/mm-mtree.sh -F "${CROSSENV}" -D
> > "${RD}/trees/base"
> >          touch ${.TARGET}
> >
> > I use a one-line patch locally to bootstrap etcupdate into the worlds I
> > package up at work via a similar one-liner.
> 
> And this is why sending out patches for review is a good idea. I've 
> updated my code to call into this script, though it would be nice if, 
> say, make distribution handled this. Thanks for pointing it out.
> 
> >> Test ISOs for amd64 and i386 can be found here:
> >> http://people.freebsd.org/~nwhitehorn/bsdinstall-amd64-20110222.iso.bz2
> >> http://people.freebsd.org/~nwhitehorn/bsdinstall-i386-20110224.iso.bz2
> >>
> >> More recent test ISOs, as well as ones for other architectures, may be
> >> available at:
> >> http://wiki.freebsd.org/BSDInstall
> >>
> >> Bug reports would be very appreciated at this time. There are three
> >> known bugs currently, which will be fixed soon, so please don't report
> >> these: error reporting is not graceful if there are no writable disks in
> >> the system, you must select at least one optional component, and the doc
> >> build is not currently connected to the releases.
> >>
> >> There are some changes to the distribution format involved in this
> >> patch, which are outlined below, and about which I would also appreciate
> >> feedback:
> >> - The src tree is not split up into pieces (e.g. ssbin) as with sysinstall
> > I would at least like to have src split up into two pieces:
> >
> > 1) would be equivalent of sbase and ssys of old distributions, so you could
> > choose to just install kernel sources along with the top-level Makefile bits
> > to build kernels.  I commonly install this subset on production machines so I
> > can install a custom kernel in a pinch.
> >
> > 2) would be everything else in the source tree.
> 
> This is a little bit tricky, since it involves inter-distribution 
> dependencies which don't currently exist (e.g. you need sbase for ssys 
> to be useful, and for severythingelse to be useful). I suppose that the 
> top-level Makefile bits are small and could end up in both archives, 
> where one can overwrite the other with the same thing. Would that solve 
> your problem?

Hmm, my thinking is ssys would include sbase, and severythingelse would
require ssys.  That is already true since libc needs syscall.mk from the
kernel sources anyway.  From a user perspective you end up with three
choices: no sources, kernel sources, or all sources.

-- 
John Baldwin