conf/163508: [rc.subr] [patch] Add "enable" and "disable" commands to rc.subr

[Chris Rees]

On 25 December 2011 07:20, Maxim Ignatenko <gelraen.ua at gmail.com> wrote:
> The following reply was made to PR conf/163508; it has been noted by GNATS.
>
> From: Maxim Ignatenko <gelraen.ua at gmail.com>
> To: Doug Barton <dougb at freebsd.org>
> Cc: bug-followup at freebsd.org
> Subject: Re: conf/163508: [rc.subr] [patch] Add &quot;enable&quot; and
>  &quot;disable&quot; commands to rc.subr
> Date: Sun, 25 Dec 2011 09:15:44 +0200
>
>  On 24 December 2011 22:59, Doug Barton <dougb at freebsd.org> wrote:
>  > On 12/24/2011 04:20, Maxim Ignatenko wrote:
>  >> The idea was to make enabling/disabling services less error-prone.
>  >
>  > How is adding foo_enable=1 to rc.conf error-prone?
>  >
>
>  Typo like fooo_enbale=1, or one missed '>' in echo foo_enable=1 > /etc/rc.conf

Let's think about this in a historical way...

We (the BSDs) with our rcng have a massive advantage over the horrors
of configuring a SysV init system; has anyone recently tried to change
the 'runlevel' of a service on Debian without using rc-update? It
involves putting numbered symlinks into each rcX.d

We don't have this problem, it's as simple as adding a line to
/etc/rc.conf(:?local)?.

Yes, other systems have rc-update and cool magic like that, but our
system is SO much simpler that these just aren't necessary.  It's not
a case of being error-prone;

BSD:

# echo 'foo_enable="YES"' >>/etc/rc.conf

SysV:

# for runlevel in 1 2 3 4 5 ; do ln -s /etc/init.d/foo
/etc/rc${runlevel}.d/S22foo ; done

Chris