Re: enable/disable support in /usr/sbin/service
]] Olaf van der Spek
| On Sun, Mar 20, 2011 at 7:43 AM, Raphael Geissert <firstname.lastname@example.org> wrote:
| >> | In particular, considering the possibility of other init systems coming
| >> | (see #591791), would /usr/sbin/service enable/disable still be a proper,
| >> | init-system-independent, abstraction?
| >> I'm guessing service would have to learn how all other init systems
| >> work, or have a way to tell them when they are installed (so «install
| >> foo; disable foo ; change init system» still leaves foo disabled).
| > I started a discussion about this topic but with another focus:
| > http://bugs.debian.org/588085
| > (message #21 is the one closest to this thread)
| service is the UI and invoke-rc.d is the API for starting/stopping services.
| chkconfig (not yet available) is the UI and update-rc.d is the API for
| setting when services should be started/stopped.
That's not how I've understood Steve Langasek's vision of service(8)'s
role here. As an example, systemd is happy for services to have rcN.d
links and will use those and the init scripts if there's no native
service definition so there's absolutely no need for systemd to provide
its own update-rc.d wrapper.
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are