Re: CVS commit: basesrc/etc/rc.conf.d

[Darren Reed <darrenr%reed.wattle.id.au@localhost>]

In some email I received from matthew green, sie wrote:
> 
>    Actually, there wasn't even a directory there to start with, so it
>    wasn't just empty but non-existant.
> 
> this is false.  the directory is *definately* created.  i've used
> it on multiple occasions to set "command=..." for this instance.

My understanding was based on someone else's assertion (on icb) that it
wasn't created.  Fool me for believing them (I should have checked locally
but I was lame)

> luke has backed it out.

so i found out afterwards.

> you can blame yourself for not talking to anyone about this
> first.  you can blame yourself for thinking you understand what
> rc.conf.d is for.  you can blame yourself for assuming "support"
> means "provide defaults".  most of all, don't blame luke for
> talking to you, maybe he'll stop altogether. ;-)

Well stupid me thought that it didn't need talking about because
"support" was there, just nothing used it.

> darren, you just stomped all over this and you show no sign of
> listening to what other people say.

nobody seemed to be listening to me so why be surprised that i
didn't listen to anyone else ?

> you continually ignore it
> when people say "rc.conf.d is completely for the end user" and
> "put this into defaults/rc.conf".

if that's truely our approach then I think we're being lame.
things like sushi could benefit tremendously from proper use
of rc.cond.d.

>  the features you added are
> now gone but you're more than welcome to add them, given you use
> _lower case_ variables, to defaults/rc.conf.

is "lower case variables" mentioned as a requirement anywhere ?

fwiw, I generally use upper case variables in shell scripts for
"global" use, not just because I've seen it elsewhere.  at least
for me it greatly aids readability by making variables distinct
from program names, paths, keywords, etc.