From owner-freebsd-rc@FreeBSD.ORG Sat Dec 24 23:11:23 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 544CA106564A; Sat, 24 Dec 2011 23:11:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E63628FC14; Sat, 24 Dec 2011 23:11:22 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pBON8rUp014204 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 24 Dec 2011 16:08:53 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4EF64915.4030006@FreeBSD.org> Date: Sat, 24 Dec 2011 16:08:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201112241230.pBOCUF3h064098@freefall.freebsd.org> <4EF64915.4030006@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sat, 24 Dec 2011 16:08:53 -0700 (MST) Cc: Maxim Ignatenko , freebsd-rc@freebsd.org Subject: Re: conf/163508: [rc.subr] [patch] Add " enable" and " disable" commands to rc.subr X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 23:11:23 -0000 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