conf/163508: [rc.subr] [patch] Add " enable" and
" disable" commands to rc.subr
Lars Engels
lars.engels at 0x20.net
Sat Dec 24 16:57:26 UTC 2011
On Sat, Dec 24, 2011 at 09:48:37AM -0700, Warner Losh wrote:
>
> On Dec 24, 2011, at 6:15 AM, Chris Rees wrote:
>
> > On 24 December 2011 12:30, 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 "enable" and
> >> "disable" commands to rc.subr
> >> Date: Sat, 24 Dec 2011 14:20:19 +0200
> >>
> >> On 24 December 2011 04:15, Doug Barton <dougb at freebsd.org> wrote:
> >> > This idea has been considered before and rejected because it's too
> >> > difficult to catch all the corner cases, and actually editing a config
> >> > file is not really all that hard of a thing to do.
> >> >
> >>
> >> The idea was to make enabling/disabling services less error-prone. It
> >> don't need to catch _all_ corner cases, because if administrator do
> >> something unusual with startup configuration he should be able to
> >> manipulate it in proper way, or even have tools that do something
> >> similar.
> >> Proposed patch handles /etc/rc.conf, /etc/rc.conf.local and
> >> /etc/rc.conf.d/* properly (I hope), so it should fit nicely in 95% of
> >> cases.
> >> Doing `service someserive enable` is much faster and less error-prone
> >> that `service someservice rcvar ; echo someservicercvar_enable=YES >>
> >> /etc/rc.conf`
> >
> > Disagree, sorry.
> >
> > If we're going to implement these ideas we should do it properly, not
> > for 95% of cases.
>
> A lot depends on what those 5% of the cases are. Absent an
> implementation to throw stones at, such criticism is premature. If
> the 5% of cases are when someone has done something complicated to the
> rc.conf file, then I don't care: they won't use this interface and we
> can detect this case and do nothing. If the 5% of the cases are when
> someone has enabled ntpd, then that would be a non-starter.
Yup, let's better fix the 5% of special cases where the new features
doesn't work.
I know and like the "enable / disable" arguments to "svcadm" from
Solaris and miss it on FreeBSD.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20111224/160f1f9c/attachment.pgp
More information about the freebsd-rc
mailing list