> commands.  That is, if one reran all the same programs with the same
> parameters, one would get an identical installation.  (The only things
> that might not be done this way are files that get written to /etc (/mnt/etc)
> and they could be added to the script file by approiate calls to echo.)

Yes. It should be possible to run sysinst in a mode where it spits out a
shell script, which can be run later. This is an _excellent_ way to teach
people about the basic layout of things and the booting process -- they can
just run 'man' on every command they see.

It also is much more flexible. People can tweak it, or they can save it off
and run it again later if they want to replicate that installation on another
machine with similar hardware.

>>Either way.. I'll get started this week on banging away at that stuff.. looks
>>like I need to either sacrifice a box for this.. or hack it to issue dummy

I have a sacrificial box (complete with El Crappo pre-SVGA monitor) now. It
is still learning how to build the 1.3.2 release sources -- I wanted to get
familiar with the stable sources and how they build before I tackled sup and
building -current.

As of yet I have not made any changes to sysinst. I have also emailed some
people on the NetBSD web pages whose projects might touch sysinst, and got
either no reply or an explanation that their project was long dead. So I
think that leaves you and me as the ones who are currently interested in
active work on sysinst.

Basically I think it will work best if you go full steam ahead on your
favorite changes and I'll volunteer my sacrificial machine as the first
alpha site. Later on I would like to take over the job of sysinst maintainer
but right now there are just too many dimensions in which I have to get up
to speed.

> Earlier versions of sysinst had a compile switch to allow one to
> just echo commands and not run them.  The last time I tried it, it 
> didn't work very well.  It would be real nice if it worked again,

There's an inherent danger with "dryrun" options -- if any decisions depend
on state changes that relied on previous commands actually executing, you
have to simulate that in the logic and there is always the risk that the
simulation will be incorrect. Another reason I prefer the script model is
that it discourages coding practices which run into trouble this way...

Todd Whitesel
toddpw @ best.com