On 26 December 2011 08:12, Doug Barton <[email protected]> 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. >
Proposed patch searches all files (except /etc/defaults/rc.conf) that are included by load_rc_config() in _reverse_ order, so even if there are some other files included in rc.conf, foo_enable=NO gets added to the end of last processed file and we still have foo enabled. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-rc To unsubscribe, send any mail to "[email protected]"
