Subject: Allowing ${name}_path to be set in "rc.conf", was Re: Keeping
To: Andrew Doran <ad@interlude.eu.org>
From: Frederick Bruckman <fredb@immanent.net>
List: tech-userlevel
Date: 12/28/2001 09:33:44
On Fri, 28 Dec 2001, Andrew Doran wrote:

> Frederick Bruckman <fredb@immanent.net> wrote:
>
> > The question is, whether the syntax of "rc.conf" should be extended to
> > permit changing the path *to* *the* *executable*, in order to make custom
> > rc.d scripts unnecessary.
>
> How about having the ability to override the standard scripts entirely? For
> example: the system has a script (or a dependancy, whatever it's called)
> named sshd, and I have a custom script named sshd, so rc.subr chooses my
> script beacause it's obviously far more hip - or something along those
> lines. Does that sound like a reasonable idea?

Uh, no. That's what we're trying to avoid. ;-)

If it's *really* cooler, than you merge it into your cvs checkout now,
and submit it as a change-request later, at which time it'll either be
accepted, or you'll be talked out of it, or perhaps you'll even be shown
a better way of doing whatever it is you've set out to do.

The one sort of change that you really *wouldn't* care to share is a
simple change to the path of the executable daemon. By moving that
change into "rc.conf", you pave the way for "make build" and "pkgsrc" to
keep everybody's rc.d in sync.

That change I'm advocating involves a minor change to "rc.subr", and
some doc changes. All the alternatives seem to require massive changes
to "rc.subr", changes to "rcorder", and moreover, they would tend to
break the elegant simplicity of the "rc.d" scheme.

Frederick