Subject: Re: CVS commit: basesrc/etc/rc.conf.d
To: Tim Rightnour <firstname.lastname@example.org>
From: Frederick Bruckman <email@example.com>
Date: 04/19/2002 12:52:27
On Fri, 19 Apr 2002, Tim Rightnour wrote:
> On 19-Apr-02 Luke Mewburn wrote:
> > what about just having a section at the top of the rc.d script itself
> > that sets the defaults?
> >From sushi's point of view, that wouldn't be so bad. However as a user not
> using sushi, it would be really annoying. Right now you can look in one place
> to find out what the defaults are. By cutting it apart, you would be forced to
> look in a zillion places.
That's why I suggested generating a defaults file from a meta-form,
but that has other pitfalls. There's stuff currently in defaults that
operates on the rc system directly, and doesn't correspond to any rc.d
script. Plus, you're not going to be able to boot multi-user if there
are any syntax errors in the defaults file. Perhaps we could just
dynamically build an examples file, that isn't actually sourced?
> > --> new section follows
> > --> contains "defaults: " and then a description of what it does
> > this could be used by a script to build the default sushi form files
> > as well...
> It would need a variety of additional things. As Fredrick says in another
> email, there are a few more things sushi would need to build the form file.
> However, rather than trying to come up with YA meta-language that sushi would
> parse and create a form file from, it might be easier to embed the form file
> lines in the script itself. Assuming we changed to this method, one could
> simply put the required form lines at the top of each script, and have a
> makefile target that regenerates the sushi form file. An added bonus would be
> that said build process could use rcorder, and the form would be in execution
> order. :)
Hmm.. who wants it in execution order? We may want a "categories"
tag, to arrange it much as it is now.
Another thought: the fashionable, state-of-art meta-language is xml.
If that's too ugly to embed in the script (and yes, I see the point),
we could put it all in a shadow directory, like /etc/rc.d.xml. I'm
sure we can parse whatever subset we choose to implement with "awk",
of course -- no need to import a new library. Just a thought...