Date: Sun, 25 Dec 2011 23:06:08 -0800 From: Doug Barton <dougb@FreeBSD.org> To: Garrett Cooper <yanegomi@gmail.com> Cc: Maxim Ignatenko <gelraen.ua@gmail.com>, "freebsd-rc@freebsd.org" <freebsd-rc@freebsd.org> Subject: Re: conf/163508: [rc.subr] [patch] Add " enable" and " disable" commands to rc.subr Message-ID: <4EF81CE0.9080802@FreeBSD.org> In-Reply-To: <286B56F0-CD3B-4B1C-A5DE-45BC2CAFEB89@gmail.com> References: <201112241230.pBOCUF3h064098@freefall.freebsd.org> <D9E8E12B-7E7F-4164-802F-4F6FE7DFB397@bsdimp.com> <4EF64915.4030006@FreeBSD.org> <DE3E9178-9610-4014-AABA-32C66823C1B8@bsdimp.com> <4EF8105D.3030907@FreeBSD.org> <286B56F0-CD3B-4B1C-A5DE-45BC2CAFEB89@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/25/2011 23:00, Garrett Cooper wrote: > On Dec 25, 2011, at 10:12 PM, Doug Barton <dougb@FreeBSD.org> wrote: > >> 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. > > Using multiple rc.conf files is an advanced feature. IMO, the same constraints for Devin Teske's sysrc tool should apply here: > 1. The tool will only work with one rc.conf file. > 2. Simple rc.conf declarations are allowed, but evaluated statements can't and won't be handled by the script/infrastructure. > Once the caveats are documented and understood, we should have the bases covered, s.t. this will handle the majority of the valid cases that the patch is attempting to address. I think that it sounds great to say "do this, and no more," but that ultimately trying to limit the scope in this way is going to cause way more problems than it solves. But, now I'm repeating myself. If you (Garrett) are willing to commit to both the short and long term support of users and code affected by this change (as described in my points 2. and 3. above) then I wish you all the best. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EF81CE0.9080802>