Request for review/testing: switching the default installer
John Baldwin
jhb at freebsd.org
Wed Mar 2 16:47:53 UTC 2011
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
More information about the freebsd-arch
mailing list