From owner-freebsd-rc@FreeBSD.ORG Sat Dec 24 21:50:14 2011 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 45A7E106564A for ; Sat, 24 Dec 2011 21:50:14 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 0C4EE14F3DE; Sat, 24 Dec 2011 21:50:14 +0000 (UTC) Message-ID: <4EF64915.4030006@FreeBSD.org> Date: Sat, 24 Dec 2011 13:50:13 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Warner Losh References: <201112241230.pBOCUF3h064098@freefall.freebsd.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 21:50:14 -0000 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." 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. 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. Which returns me to my original point, how hard is it to edit rc.conf anyway? Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/