>I like the idea of rc.d, but I think the concept of rc.conf conflicts with
>that design and should go.  I think each individual rc script should have
>a small configuration section at the top which is editted directly.

no!  that's wrong!  please!

in the beginning, there was no rc.conf file and all changes in boot
behavior were done by changing rc and rc.local.  this made upgrades of
/etc particularly painful and i avoided it at all costs.  then rc.conf
was invented and there was much rejoicing.

rc and rc.local (well, maybe not so much) were now mostly left alone
and could be upgraded with a relative degree of impunity.

several eons passed...and the work of luke fell into /etc.  the rc.d
system was born, breaking rc into little tiny fragments.  some said it
was good, some said it was bad.  from my point of view, it's made up
of stuff that i can't *imagine* needing to touch, so it's nice.  it's
something i can upgrade with almost *complete* impunity (and imagine
my surprise when the nfsiod stuff disappeared a few days ago :).

upgrading rc.d (feel free to point out my stupidity here) is now, for
me at least, as easy as defining destdir and building the world.  then
all i do is diff my /etc/rc.d with the new one, noting files that have
changed (copy the new one over), disappeared (remove mine unless i
recognize it as my own thing), or appeared (copy a new one in).

rc.conf remains and centralizes the actual configuration of the
machine.  imho, this is a "good thing".  breaking it into little tiny
fragments would be akin to going full circle and breaking the
monolithic rc of times gone by into little pieces with no facility for
maintenance.

something that freebsd did (which confused me at first, but seems to
apply to this situation a little) is provide an rc.conf.defaults file
(or something like that) with defaults for everything so that your
rc.conf file only needs to override those defaults.  i get a much
clearer picture of what i've changed that way.  i guess you could do
the same with a stock rc.conf and have it check for (and source) the
file /etc/rc.conf.local.  then i could upgrade my rc.conf easily too.

but if i have to start mucking in all the little scripts to turn
things on and off and change the way they run, then i'll be upset.  rc
will have gone from monolithic to microlithic.  upgrades will go back
to being a pain.  if a virc program is needed to maintain the system,
when vi used to suffice, i think it's the wrong direction.

>But I really do not want to see are 1000s of little rc.conf.d/*.conf
>scripts that need to be kept in sync with the stuff in rc.d.

agreed.  that would be wrong, too.

>I think a reasonable compromise is to have the rc.d scripts set variables
>that can be overridden in rc.conf, and some utility to synchronize rc.conf
>with the rc.d scripts when the system configuration is changed.

rc.conf should stay.  please?

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."