On Fri, 24 Mar 2000, Kenneth W Cochran wrote:
> So buildworld runs in its "own complete isolated" environment?
> IOW, buildworld uses its "own" tools, etc., & doesn't need ie.
> /bin, /usr/bin ... ?? (Except for a few basic things, like the
> compiler (with which to "bootstrap" itself?"... :)
Exactly. The only time there are snags is when an install or building
tool is not included in the world building tool chain. AFAIK, this is the
reason for the installworld -DNOINFO hack. install-info is not part of
the build chain, but the install relies upon it (and in the case of the
3.x->4.0 upgrade, it relies on a new feature for the version not yet
installed on the system). I could be mistaken on this point, but this is
how I interpreted the discussion on -current.
> >cvs-crypto
>
> UPDATING says "Crypto & secure are now required." That, as I
> understand would be src-crypto and src-secure. How would these
> differ from cvs-crypto? Ie. would it be "better" to use those 2
> "tags" or to use the one cvs-crypto? I suppose what I may be
> asking is "how do I make my new system look most like the
> distributed CDs?"
As mentioned in another reply, cvs-crypto is simply a crypto catch-all
tag. I prefer it because I want all crypto and thus I see it as
cleaner. It's just personal preference though.
> >If you want the latest ports collection and documentation, specify:
> >ports-all tag=.
> >doc-all tag=.
>
> I do that with a separate cvsup file/job...
Why? Cvsup ports and docs more or less often? I just lump them all into
my sup-file, along with src-all and cvs-crypto for RELENG_3, RELENG_4, and
-CURRENT, all going into different directories. That way I can read
through the source changes to all of the active branches, or
upgrade/downgrade any way I want.
> >supfile using something like:
> >*default host=cvsup.FreeBSD.org
>
> I use one "closer..."
Yeah, that was what I was getting at with the "something like" :)
> >cd /usr/src/sbin/mknod && make install
>
> Along the lines of "dotting all the "i"s & "crossong all the
> "t"s", I believe it would be a Good Idea to make this more
> explicit in the instructions... :)
Warner Losh is the man in charge of the UPDATING file. You might want to
pass the suggestion along to him.
> My devices are indeed da*; it was fresh-installed from the
> 3.4-RELEASE CDs, so it appears that I can skip this step?
> My /etc/fstab should also be ok?
It should be. I have had no problems, but disks and devices are not my
strong area.
> >You need the new MAKEDEV script for 4.0 from /usr/src/etc. As
> >far as I know, once you copy the new script into /dev, 'sh
> >MAKEDEV all' should work fine. I could be wrong for certain
> >configurations.
>
> Hmmm... <scratching chin...> Perhaps this needs more clarification?
Again, devices are not my cup of tea. I have always just copied the new
MAKEDEV into /dev and run 'sh MAKEDEV all'. Never had any problem, but
again, that doesn't mean I haven't been doing something wrong.
> >You probably should boot into single-user, but I have done it
> >successfully after booting multi-user.
>
> I'm one of those "safety freaks" who always goes single-user for
> installworld... :)
That's probably smart. I am sure some day I will get bitten doing
this. Until then, I will probably just live dangerously.
> >For the upgrade, yes, install GENERIC. Once you have rebooted
> >after the upgrade, it is much safer to rebuild your custom kernel.
>
> So, substitute GENERIC for "YOUR_KERNEL_HERE?"
GENERIC for the initial upgrade kernel, YOUR_KERNEL_HERE after upgrade
complete.
> I think it would be a Very Good Idea to get "appropriate
> portions" of this information into the UPDATING instructions; it
> might help slow down the upgrading-deluge "here" on -stable... :)
Again, send your suggestions to Warner Losh <[EMAIL PROTECTED]>. He
maintains the UPDATING file.
Enjoy 4.0.
- Matt
--
Matt Loschert [EMAIL PROTECTED]
Software Engineer voice (703) 847-1381
ServInt Internet Services fax (703) 847-1383
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
