Date: Sat, 24 Dec 2011 16:08:52 -0700 From: Warner Losh <imp@bsdimp.com> To: Doug Barton <dougb@freebsd.org> Cc: Maxim Ignatenko <gelraen.ua@gmail.com>, freebsd-rc@freebsd.org Subject: Re: conf/163508: [rc.subr] [patch] Add " enable" and " disable" commands to rc.subr Message-ID: <DE3E9178-9610-4014-AABA-32C66823C1B8@bsdimp.com> In-Reply-To: <4EF64915.4030006@FreeBSD.org> References: <201112241230.pBOCUF3h064098@freefall.freebsd.org> <D9E8E12B-7E7F-4164-802F-4F6FE7DFB397@bsdimp.com> <4EF64915.4030006@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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...=20 >=20 > Warner, >=20 > 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=3DNO 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=3Dyes forces foo_enable=3Dyes 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DE3E9178-9610-4014-AABA-32C66823C1B8>