Greg A. Woods wrote:
> At Mon, 19 Mar 2007 20:10:12 -0700,
> Scott Ellis wrote:
>>   The root of what is being proposed is the ability to use rc.d/ stype
>> scripts rather than the rc.local file.  The proposal to extend rc.local
>> into "modern" NetBSD times by allowing rc.local.d/ seems reasonable, and
>> preserves the differentiation between 'OS' and 'local' scripts.
>>
>> I for one welcome the thought of an rc.local.d/ .
> 
> I can assure you that such artificial separation of things that are best
> kept together is a very BAD idea.  It leads to frustration and
> unnecessary complexity, and those things _always_ lead to very serious
> mistakes even by the most careful of system managers.

That same argument can be made against the current (and historic) 
rc.local.  Are you proposing that rc.local support be removed?  (I don't 
think you are, but I'm failing to see the difference between rc.local 
and rc.local.d in concept.)

> The current system is very simple and very easy to manage (when used
> correctly), regardless of whether add-on packages are installed manually
> or via pkg_*.

That is a bit subjective (as is the majority of the discussion).  I 
believe the original proposal was to overcome a (at least perceived) 
problem.  Does adding rc.local.d (or whatever) preclude doing it the 
current 'very simple and very easy' way?  I didn't see that it did.  At 
the same time, it makes life easier for some folks (who for whatever 
reason choose not to use the current unified rc.d).

I'm not arguing _for_ and rc.local.d, just chiming in that I've found it 
an odd thing to be missing, and personally prefer that model of keeping 
vendor-supplied scripts separated from site-specific scripts.

	ScottE