On 27 Dec 2001, Laine Stump wrote:

> Greywolf <greywolf@starwolf.com> writes:
>
> > On 26 Dec 2001, Laine Stump wrote:
> > # Leading me to wonder out loud if maybe there shouldn't be two stages
> > # of rc.d, for example's sake call them "/etc/rc.d.defaults" (or maybe
> > # /etc/defaults/rc.d) and "/etc/rc.d". The former would contain the
> > # "factory" versions of all the files, and would be automatically
> > # updated by a make build, or a binary upgrade, while the latter would
> > # not be touched by either operation. The two directories would be
> > # treated kind of like a union file system, with files in /etc/rc.d
> > # taking precedence over the same file in /etc/rc.d/defaults.
>
> > 1.  Isn't /etc/rc.d/* supposed to depend upon stuff from /etc/rc.conf,
> >     and not need mangling?
>
> Yes, but from the previous messages, that is apparently not the case
> (I know I haven't modified any stock files in my /etc/rc.d, but I
> guess some people have, or at least believe that they should be able
> to).  If comments to this effect hadn't been made, I wouldn't have even
> been thinking about separating local changes from stock files.

Hey, there's nothing wrong with brainstorming. I thought about it,
though, and it looks really messy. You'd need a modification to
"rcorder" at least, and that begs the questin of how "rcorder" is to
decide which one of two identically named scripts gets chosen.

On the other hand, when I think about *why* I have changed rc.d scripts,
and why there are customs scripts in pkgsrc, it's mostly just to change
the path. It's looks pretty doable to change "rc.subr" to take the value
given in the rc.d script for $command as the default, but to allow it to
be overriden with a ${file}_path variable, and that would eliminate most
of the reason to maintain custom scripts.

Frederick