From owner-freebsd-rc@FreeBSD.ORG Mon Dec 26 06:12:46 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 6F35A106566C for ; Mon, 26 Dec 2011 06:12:46 +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 E51C3177915; Mon, 26 Dec 2011 06:12:45 +0000 (UTC) Message-ID: <4EF8105D.3030907@FreeBSD.org> Date: Sun, 25 Dec 2011 22:12:45 -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> <4EF64915.4030006@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: Mon, 26 Dec 2011 06:12:46 -0000 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/