conf/163508: [rc.subr] [patch] Add " enable" and "
disable" commands to rc.subr
Doug Barton
dougb at FreeBSD.org
Mon Dec 26 06:12:46 UTC 2011
On 12/24/2011 15:08, Warner Losh wrote:
>
> 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.
You do get that the OP included a patch, right?
>> 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.
No, you seem to be missing my point. Because of the way that rc.d
processes the various *conf* options the last match "wins." So let's say
that you had foo_enable=0 in /etc/rc.conf; but one of the conf files
that's processed later has foo_enable=1. If that's the last match, it
gets started. This is one of the many concerns regarding trying to
automatically enable or disable things.
>> 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.
IMO that's pie in the sky.
>> 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.
I'm not convinced that's a feature, but I'm willing to be persuaded.
> Some folks also would find it easier.
Once again, I think you're missing my point. I didn't say that I don't
*like* the idea. I think it would be awesome for us to have something
like this. My point is that we've already spent quite a lot of cycles
discussing how it could be done robustly, and discovered that at this
time it's not really possible to do that.
> 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.
And worst outcome is that we waste a lot of time that could be put into
more productive areas; and screw over our users in the process. While a
good/interesting idea, this feature would be a "nice to have" at best.
My bottom line is that if you (Warner) or some group of committers want
to commit to:
1. Rigorous testing (including *all* of the various possible
combinations of *conf* files)
2. Short term support for users who are negatively impacted by any
changes you make
3. Long term support of the code (and by long term I mean at least a few
months past the release of FreeBSD 10.1)
Then I say "go for it." Short of that level of commitment you're just
creating a big mess and then expecting other people to clean it up.
Doug
--
[^L]
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
More information about the freebsd-rc
mailing list