Subject: Re: Sorting out the SRC (was a is not alpha)
To: Andrew Diller <netbsd@dillernet.com>
From: Colin Wood <cwood@ichips.intel.com>
List: port-mac68k
Date: 11/03/1997 09:53:42
Andrew Diller wrote:

BTW, just as a side note, I'm not too sure that your reply-to address is
valid.  I think that you sent me about 4 emails which I responded to
directly which then bounced back to me undelivered :-(  Make sure you send
mail from a valid address...it's a pain to have to go dig one out to send
mail to. :-)

> At 12:10 PM 11/2/97 -0800, you wrote:
> 
> >Bill wrote:
> 
> >The easiest thing to do (if downloading's cheep) is to just install the
> >1.3_alpha release. Then you won't have to compile anything, except possably
> >your own kernel.
> >
> I think I am understanding what is going on here.  AGain, I'll use Linux as
> a comparison.
> 
> ----------------
> Linux-- the 'base' system i.e. most everything except the kernel remains in
> place while you can upgrade the kernel as new releases become available.
> 
> MacBSD-- with a new kernel, you recompile all the binaries using that
> kernal and create these snapshots, essentially a whole new release.
> -----------------

Not quite.  The vast majority of binaries can be kept, provided that no
major changes occur to certain kernel interfaces (there are plenty of
people running 1.3_ALPHA kernels with 1.2.1 binaries right now, I'm sure).
The reason why we recommend keeping kernels and binaries in sync is that
users will often encounter problems with binaries which use libkvm to
access the kernel (like ps, w, and netstat) if these get too far out of
sync.

There can be other problems as well, tho...the minor number for libc can
change with the addition of new system calls, and this can often break a
few programs (or the major number can change and break a lot of things
like it almost did 2 weeks ago ;-)

In general, newer binaries usually contain more functionality and bugfixes
than older binaries as well...so while you can stick to your older
binaries, it's generally in your best interest to upgrade if you're going
to upgrade your kernel.

> Ok, that make sense-- but what exactly are we talking here as an upgrade path?
> 
> If I have 1.2.1 and now want 1.3alpha (and then 1.3) I have to reinstall
> the whole thing??

Well...not really.  Generally, the base package contains most of the stuff
that's going to cause a problem (admittedly that's the biggest package,
too, tho).  Like I said above, you could probably get away with just
upgrading the libkvm-based utilities...

> What about the newer snapshots of 1.3alpha-- do I need to reinstall the
> whole release, or am I safe reinstalling the newer 'snapshots' right ON TOP
> of my exising 1.3alpha system??

Oh, you'll never need to do a complete reinstall (i.e. reformat and
re-Mkfs or something like that).  All you need to do is untar the new
archive over the old one.  I recommend something like:

cd /
tar --unlink -xzvpf base13

or whatever the package is named (and do this from single-user mode, it's
much hairier from multi-user mode).

As for newer "1.3_ALPHA" snapshots, there probably won't be any.  We
should be hitting 1.3_BETA before too long, and the 1.3 release is
scheduled for early December.  There shouldn't be any major changes
between 1.3_ALPHA and the 1.3 release binaries.  Only bugfixes are allowed
in at this point.  So, if you have 1.3_ALPHA binaries, you should be able
to run a 1.3 kernel with no troubles...just keep in mind that there might
have been bugfixes to the binaries which you might want to get :-)

> These may sound like strange questions, but again, My experiences with
> other UNIX's (AIX, IRIX and Linux) when you changed kernels, you left most
> of the binaries in place.

Well, it kinda depends on how often you change your kernels.  If you
upgrade from say Solaris 2.4 to Solaris 2.5, you're pretty much going to
have to go through a full reinstall from tape (or is it CD these days).
Same is probably true for most commercial Unices.  However, if you're only
installing a patch-release kernel, no, you wouldn't upgrade your binaries.
The same could be said for patch-releases in NetBSD.

> I guess its like you all have said in your helpful replies-- so MUCH is
> happening between the releases that it makes sense to re do ALL the
> binaries for the releases. I guess that Linus and the wintel machines at
> least have documentation for the devices they were writing for.

This is quite true...although the advice to upgrade all of your binaries
applies to all the NetBSD ports (and there are quite a few), i386
included.  There are so many changes to the machine-independent portion of
the kernel and userland that it just makes sense to do so.

> With that said, its kinda insane that you all have been able to do what you
> HAVE done.  Its really nice (and cool) to have my mac friends come over and
> see my se/30 now running X and fvwm-- hell, even the people that I know who
> run Linux are impressed that I'm running the LATEST fvwm on an 8 meg 9"
> Macintosh. Its so cute.

It's pretty amazing, isn't it? :-)

> Now, if I can just get a kernel that will work on my Quadra 605, cause it
> would be nice to use an 040.....

Well...if only we could get internal video working correctly and reliably
on that machine!  Perhaps you'd like to help with the effort?  Your 605 is
a full '040, correct?

> To sum up-- I am going to get the latest 1.3alpha snapshot, install that as
> my new system and then recompile all the things that I had done under
> 1.2.1.  Then when the final 1.3 kernel comes out, I should be in good
> shape, and I can try some different kernels for my other macs.

BTW, you _don't_ need to recompile all of your binaries if they are not
part of NetBSD.  I'm still using several binaries which I compiled under
NetBSD 1.1 :-)  Third party stuff should continue to work just fine as
long as the libc major number doesn't change, I think.

I hope this helps.

Later.

-- 
Colin Wood                                 cwood@ichips.intel.com
Component Design Engineer - MD6                 Intel Corporation
-----------------------------------------------------------------
I speak only on my own behalf, not for my employer.