[Note: rearranged a bit, and paragraph headings because I seem to
have rambled on a bit.  I feel that all I said is worth saying though.
(well, of course I do, I wrote it. :) )]

On Sat, Apr 01, 2000 at 09:13:25PM -0800, Greywolf wrote:
> You may consider this a strong vote against any further fragmentation
> of the RC configuration.  I don't think it's a practical move.  There
> has GOT to be a better way of handling this without going the way of,
> say, IRIX.
	I agree on this point.

> Sigh.  Luke, you know, I appreciate the effort that's going in here, but
> splitting out rc.conf into a bunch of little files makes it a huge pain
> in the patella when trying to configure the box.  Never mind the cute
	and I agree here.

> little script that will be required to enable/disable "features"
> as needed.  Not being able to read a single config file to determine
> what is running on the system is really detrimental both in terms
> of functionality as well as, yes, what makes this BSD.

> As soon as I get DSL going, I'm going to set up a repository, if I can,
> which will contain a preserved old-world-mode rc scheme.  This will be
> available for _and maintained by_ the people who determine that a monolithic
> rc, a monolithic rc.conf or both are preferable to the nightmare that
> a split-up rc.conf will be.

	However, I have to disagree on the idea of reverting to back to
a monolithic /etc/rc.  (although, you of course are free to setup whatever
repository you want)

[ease of adding new software:]
	I think that there should definitely be a single rc.conf which you
can look at to see what is configured on the system.  However, I also
think that it should be possible to define a default value for each script
in rc.d which can be overridden by rc.conf.  This means that any additional
installed software can get itself to start merely by dropping a file in
/etc/rc.d without having to worry about parsing and editing a configuration
file.  (which is one of the goals of the rc.d scheme)  

[enable/disable util:]
	The enable/disable script seems like it is irrelevant to the
basic operation of this system because it is not necessary.  The default
method of operation is the single config file modified using vi, emacs,... .
	Sure, it might be nice to have a util that can allow a configurable
subset of users to change the configuration on certain commands, but I
have a feeling that this is just asking for a bunch of security problems.
Also, I wonder just how common the need for something like this is and
whether, since what to allow to be configured for each particular program
will need to be carefully thought out anyway, this functionality is better
left to a custom script written for the particular situation.

[show default config util:]
	On the other hand, I can see a need for a default options checking
utility which can list the default enabled/disabled status and arguments
of any script that is in rc.d but not in rc.conf.  This is to let you see
what the default configuration is while the contents of rc.conf might only
be the differences from the default.

[exit status dependancies:]
	Finally, the direction I think would be really cool for the rc.d
scheme to move in is eventually allowing later scripts to depend on the
actual exit status of what they depend on instead of just the
PROVIDE/REQUIRE lines.

[monolithic conversion scripts:]
	One great benefit of the rc.d scheme is that it is more flexible
than the previous monolithic /etc/rc.  If you really want to see a single
script that runs at startup it is fairly easy to convert from /etc/rc.d to
/etc/rc.  You could even set things up so this happens as the first
thing in the startup sequence (or perhaps the last in the shutdown) so
you always have an up to date /etc/rc even if the contents of rc.d changes.
This wouldn't be too hard even with the exit status dependencies.

	If you really want a single rc and rc.conf I urge you to implement
a method somewhat similar to this instead of creating a NetBSD micro fragment.
There doesn't seem to be much sense in dividing our efforts on two completely
disjoint configuration methods when the features of both can be easily done.

eric