Tim Rightnour <root@garbled.net> writes:
>Like I said.. it would be perfectly reasonable to do this to sysinst.. and
>break it in half later. It might be smarter..  as you don't want to take on to
>large a reconstruction all at once.

So, I've thought a bit about sysinst, and in my opinion, you're
seriously jumping the gun in trying to figure out how to break it up
into separate programs or something.

The largest problems in sysinst right now, in my opinion, are:

* data structures

* data collection/menu system.

The data structures need to be more object oriented, e.g. there needs
to be a generic facility to get configuration information for a
network interface (and you should be able to and it should be easy to
configure all of them).

The data collection and menu system are ... interesting.  the biggest
points are: it needs to be much more dynamic, e.g. you should be able
to easily create a menu on the fly which contains all of the media
choices for a given interface; and the screens for collection need to
be better navigable, e.g. you need to be able to go back to the
previous screen in a set of screens, from any screen.


Once the data structures are sane, then the importing and exporting of
the data structures, as well as updating them via configuration
screens if necessary, should be pretty easy.  Further, if sysinst's
actions are driven from this data, then doing automated installs from
a script should be pretty easy.  (the only trick may be to figure out
what additional information you need, to configure the system
properly.  but that's doable...)



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.