conf/163508: [rc.subr] [patch] Add " enable" and " disable" commands to rc.subr

Warner Losh imp at bsdimp.com
Sat Dec 24 23:11:23 UTC 2011


On Dec 24, 2011, at 2:50 PM, Doug Barton wrote:

> On 12/24/2011 08:46, Warner Losh wrote:
>> Also, let's not reject  it before it is done.  Let's reject it when it actually doesn't handle the cases that are interesting.  No sense in cutting off a good feature because of some theoretical problem.  It is a problem we have sometimes in the project... 
> 
> Warner,
> 
> You seemed to have missed the bit where I said, "We've already been down
> this path once before, and it turns out to be way harder to do this
> right than it looks at first glance."

No, I get that totally.  I just don't care.  The fact that others have failed shouldn't mean we should discourage others from trying.  We shouldn't be shooting arrows at people before they are given a chance to produce something good or bad, or when they do shooting them without evaluating their work.

> Just as an example of potential problems, imagine a scenario where the
> user has foo_enable=NO in rc.conf, but the service keeps starting up
> anyway.

Most people call that a bug, or at least POLA.  The few cases in the tree where bar_enable=yes forces foo_enable=yes can be dealt with.

> For better or worse rc.d offers a lot of flexibility in how services are
> enabled. We've already heard from users who use those various
> mechanisms, and don't want them removed/broken. Absent an overhaul of
> the underlying structure of configuration files (which would violate one
> or both of remove/break existing functionality) there is no way to add
> this feature in a thorough manner. Adding it in a less-than-thorough
> manner will cause more problems than it solves.

We should encourage others solving the problem completely.

> Which returns me to my original point, how hard is it to edit rc.conf
> anyway?

Scripts would greatly benefit from having a robust way to do things without humans in the loop.  Some folks also would find it easier.

Basically, we shouldn't get in the way here by telling people it can't be done.  Then we get nothing.

Telling people to try is better.  Worst thing that happens is that this effort fails.  Best outcome is that they fix the issues to make it robust.

Warner



More information about the freebsd-rc mailing list