Date: Tue, 19 Mar 2002 13:20:03 -0800 (PST) From: Mike Meyer <mwm-dated-1017004489.c7e726@mired.org> To: freebsd-doc@FreeBSD.org Subject: Re: docs/36042: [PATCH] There's not a good description of shared builds in the handbook Message-ID: <200203192120.g2JLK3o17280@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR docs/36042; it has been noted by GNATS.
From: Mike Meyer <mwm-dated-1017004489.c7e726@mired.org>
To: Martin Heinen <martin@sumuk.de>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: docs/36042: [PATCH] There's not a good description of shared builds in the handbook
Date: Tue, 19 Mar 2002 15:14:49 -0600
In <20020319100000.A57951@sumuk.de>, Martin Heinen <martin@sumuk.de> typed:
> On Mon, Mar 18, 2002 at 09:12:19AM -0000, Mike Meyer wrote:
> > The handbook describes updating the system on a single
> > machine, but doesn't deal with the very common case of someone
> > wanting multiple machines to track the same branch.
> That's really missing and we should put the section
> into the handbook.
Thank you.
> > + machines mount that work via NFS. This section outlines a
> > + method of doing that that works.</para>
> Omit 'that works', this avoids doubling 'that'. Also all procedures
> given in the handbook should be working.
Good point - actually, most of them are good points, and I agree with
any changes I don't mention here. That sentence should end with
"method of doing so."
> > + <para>All the machines in this build set need to mount
> > + <filename>/usr/obj</filename> and
> > + <filename>/usr/src</filename> from the same machine, and at
> > + the same point. Ideally, those are on two different drives
> > + on the build machine, but they can be NFS mounted on that machine
> Building on NFS volumes isn't a good thing. Although possible,
> we shouldn't mention that here.
In which case, I think we should delete the entire sentence, and leave
make world performance issues for another section.
> > + <para>Finally make sure that the
> > + <filename>/etc/make.conf</filename> on all the machines in
> > + the build set agree with the build machine. That means that
> > + the build machine must build all the parts of the base
> > + system that any machine in the build set is going to
> > + install. Also, each build machine should have it's kernel
> > + name as <varname>KERNCONF</varname> in
> > + <filename>/etc/make.conf</filename>, and the build machine
> > + should list them all in <option>KERNCONF</option>, listing
> > + it's own kernel first.</para>
How about adding the sentence:
The build machine must have the config files for each machine in
<filename>/usr/src/sys/<variable>arch</variable>/conf</filename>
if it is going to build their kernelsp.
as the new last sentence?
> > + to the test machine, and install the kernel you just
> > + build. If this machine mounts <filename>/usr/src</filename>
> > + and <filename>/usr/obj</filename> via NFS, when you reboot
> > + to single user you will need to enable the network and mount
> > + them. The easiest way to do that is to boot to multi-user,
> > + then do <command>shutdown now</command> to go to single user
> > + mode. Once there, you can install the world and run
> > + <command>mergemaster</command> just as you normally do. Once
> > + done, use the <reboot>command</reboot> to reboot to normal
> > + multi-user operations for this machine.</para>
> The procedure is different to normal build and should be outlined
> inside <screen>.
I'm not convinced theren's enough difference to justify that. After
all, if you aren't familiar with building and installing the world on
one machine, you shouldn't be trying it on many machines. If you want
to write it up I'll be more than happy to have it included here as
well, or even instead.
> Please put two spaces at the end of sentences.
I don't write for 19th century schoolmarms. If the target format
requires that ugly anachronism, it should be taken care of by the
style sheet or the formatter. If they can't do that, give me .
and I'll use that. Or let us use -- instead of —.
Thank you for the feedback and corrections,
<mike
--
Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203192120.g2JLK3o17280>