<lukem@cs.rmit.edu.au> (Luke Mewburn) writes:

> 3. Reworking the configuration mechanism (replacing rc.conf)
...
> 	My proposal is to replace rc.conf with separate
> 	/etc/rc.conf.d/foo config files, one for each service, with
> 	contents similar to:
> 		foo=NO
> 		foo_flags="-q ex0 -p 667"

It should be specified whether these are really going to be evaluated
by /bin/sh, or just interpreted as a set of name=value pairs, one per
line, with sh-like quoting (the latter does not preclude the
implentation from using /bin/sh to interpret it, of course).

> 	The primary concern with such an approach (and it's one I've
> 	had) is that it's not as easy for a user to manage multiple
> 	services at once (or setup a system from scracth).  If a tool
> 	is provided (e.g, virc(8)) which presents /etc/rc.conf.d/* as
> 	a single editor buffer, which then rewrites /etc/rc.conf.d as
> 	necessary once the editor is successfully exitted, then I
> 	believe that this concern will be addressed.

An interesting idea. I suppose the tool could support "edit all" and
show some kind of separators in the buffer, or just edit some
command-line specified subset. Presumably the tool can enforce syntax
constraints of some sort, as vipw(8) does. 

I think it is also useful to have a tool which can be used to say
"set foo_flags in foo to blah". Do you see these as being the same tool?

> 4. Supporting pkgsrc rc.d scripts
...
> 5. Supporting third-party (non system) scripts
...

A question that was raised when this was last discussed was the
problem of namespace collision among system, pkgsrc, and third-party
scripts. I think we should be able to manually manage this for pkgsrc
(we control it, after all), but it might be worthwhile to reserve part
of the namespace for third parties and/or local scripts, which we
guarantee will not be used by the base system or pkgsrc.

        - Nathan