On 08-Feb-02 Amitai Schlair wrote:
> Please point out if I have any of this wrong, or if there are any serious 
> unaddressed issues. If we can agree that the sum of these ideas is a 
> strong improvement, then we can put them to work!

One unaddressed issue is this:

Sushi wants to understand the format of rc.conf in order to generate a pretty
display that lets the user modify it.  Currently, this is accomplished by
manually keeping rc.conf and the form file for sushi in sync.  (if you have
suggestions on other ways to do this, I suggest you look at the problem in
detail before launching them at me)

Therefore, if you just start tossing new defaults onto the end of
/etc/defaults/rc.conf.default, sushi will have no clue what they are, and not
be able to set them.

Is there a way around this?  Probably.. but I'm not about to suggest a design
to fix it, until people can agree on exactly how we would implement the rc fix
in the first place.  Otherwise I'd be designing 14 different solutions.  Most
likely it will require pkgs to add data to a sushi form file of some sort, or
create a database of entries into the rc trees.

But it's important we don't forget about this.  If we go and add features to
the system, but don't let the users set them via the tools supplied, we are
doing them a disservice, and it's not a complete solution.  Perhaps whatever
solution we come up with for this, would be the answer to the rc.conf problem
in sushi.

---
Tim Rightnour <root@garbled.net>
NetBSD: Free multi-architecture OS http://www.netbsd.org/
NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi