[ On Thursday, May 11, 2000 at 03:10:50 (-0700), John Nemeth wrote: ]
> Subject: Re: The new rc.d stuff... [now rc.conf]
>
>      I really don't understand the reluctance to have a large text file
> that can be either maintained by hand or programmatically.  There are
> several examples of this already.  One that everybody knows would be
> /etc/passwd.  A somewhat more freeform example (variable definitions
> and comments seperated into subsections) would be the M$ Windows 3.x
> *.ini files.  These files are very similar to *.conf and are usually
> maintained programmatically, but you could modify them by hand if you
> wish (and I have).  In other words, this is a solved problem.

The problem is that some anti-"rc*.d" folks (for lack of a better
identifier) haven't really admitted 100% or shown clearly that they know
what "maintenance" really means in this context and what problem is
really being solved with separate configuration files, and indeed that
it's a real problem faced by a vast majority of users, even if not by
themselves.  This isn't just an issue for third-party packages (though
indeed that's an important factor) -- it's also a critical issue for
long-term system maintenance through system upgrades and an even more
critical issue for sharing site-wide defaults in a flexible manner
between machines that must be different in subtle ways.

Please don't lock yourself into thinking of a system as an isolated
entity that doesn't undergo ground-shaking changes throughout its
lifetime of serving the requirements it was initially installed to meet.
The real problems being solved are those of life-long system management
and the scaling issues of having many slightly different machines, not
those of micro-managing one-off systems.

Your statement above shows that you haven't yet thought very hard about
how deep this issue goes and where the problems crop up.  I have in fact
proposed an example syntax that would make it at least possible to
automatically manage configuration files, either in monolithic form or
split with one per subsystem, while at the same time not requiring that
any current implementations be changed.  Unfortunately I've not heard
back from either side of the fence yet.

>      A directory barely qualifies as "all in one place" and handling a
> directory full of files as opposed to just one file is a major pain in
> the neck.

Not if you know what you're doing.  Note that I'm not saying that an
experience system administrator such as yourself wouldn't know about
some secret methodology to handle files, but rather that it's possible
for someone, perhaps especially someone with a great deal of experience,
to get stuck in a rut and not be able to think outside of the nice comfy
box they've built for themselves to find new ways of working.

In fact from a true system *maintenance* point of view, many files
separated by type/functionality/etc., but still kept in the same
directory, are *easier* to manage!  That's why folks like myself have
been advocating it, and indeed hopefully at least in part why the
changes to this effect in NetBSD have been made.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>