Michael R Zucca wrote:
> > Screen 3l: choose disk from which to install
> > Screen 3n: set up networking and nfs info
> > Screen 3f: set up networking and ftp info
> 
> You'll have to deal with HFS installs via something like hfsutils and
> don't forget to let folks install from mountable partitions as well.

Hopefully, at some point we can either get a non-GPL'd HFS implementation
working, or else get an LKM stable enough to work around this.
  
> > Install NetBSD... this would either extract tarballs from local drives,
> > from an NFS source, or download them -- hopefully in *smaller pieces* from
> > an ftp site.
> 
> Here here on the smaller pieces. I've always felt base.tgz always had alot
> of extra baloney in it. There's nothing more annoying than watching 99.9%
> of a base install to a zip take a little while and then have the installer
> spend 10 hours trying to install the timezone file for every city in the
> known universe. How many people really need the timezone files for the
> Antarctic bases? ;-)

:-)  Of course, what happens to the poor schmuck in Antarctica who
installs NetBSD on his machine and finds that he can't find the
appropriate timezone files?

> In any case it would be nice to have better control over what packages are
> installed. The "base" file should be *extremly* small. Like one meg. No more
> "big chunks" like we have now. Packages should be in more digestible pieces.
> We should also use pkginstall if possible.

Well, believe it or not, this is _very_ unlikely to happen.  There has
been significant...ummmm..."discussion" about this issue on a number of
other NetBSD mailing lists.  In general, there is very strong support for
leaving it more or less the way it is (the idea being that once you
install base, etc, and a kernel you'll have a fully working system...and 
trust me, there's at least one person who thinks that everything on
there is necessary).

> > circumstances, w/o modification.  After modifying that, if you choose, it
> > would then do the tar extractions (or whatever replaces tar in some future
> > release), write out an /etc/fstab file on the new setup based on the mount
> > information you fed it earlier, and finally, if we were really ambitious,
> > use hfsutils to write a new booter preferences file with the SCSI ID
> > changed... but probably not.)
> 
> Don't forget to build devices! :)

I believe that sysinst handles this....

> > Thoughts?
> 
> Sounds good so far. Its nice to see somebody taking on the task. It's tricky
> to write an installer. You want good functionality but you have to be
> careful to cram it into a small package. Remember, folks have to miniroot
> boot this so they have to fit the kernel, the installer, and the rest of the
> miniroot image in memory. Never mind having enough RAM left to run the
> extraction tools. Some folks want to install on machines with as little as
> 5 megs of RAM!

Believe it or not, sysinst really does handle most of this stuff already
(and it certainly fits on a floppy).  The only real hurdle before we can
use it is workable HFS support.

Later.

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