Sean Finney <seanius@debian.org> writes:
> imho i think we need to step back and re-think the entire way we're
> currently handling init scripts, both from the packaging point of view
> and from the end-user/admin point of view.
Yes.
There are two issues here.
The "short term" issue is figuring out if the current practice of
DONT_DISABLE_ENABLEMENT=false and friends in /etc/default is something
we want to keep doing.
The "long term" issue is having a toolset, for the end user, for
starting and stopping services, enabling and disabling services when
booting, installing and upgrading, and setting a global policy for what
the initial status of an installed service should be.
The end user wants to select which services start at boot, and also
directly control (start,stop,restart,status,foo,bar) services,
regardless of whether the service is set to be started at boot.
Having the enable/disable functionality inside the /etc/default/example
script ensures that the service does not start in any case, not even
when started manually, or from another service manager. Just this fact
would make it a poor solution.
The package maintainer scripts will need a way to stop a service on
uninstall or upgrade, and start after configuration, unless prevented by
policy-rc.d.
Currently, our packaged services start automatically, unless explicitly
disabled in /etc/default/<service>, or by missing configuration.
Compare this to the policy of RHEL, which does not enable or start its
services on package install.
A RHEL service can be started manually, but will not be started at
system boot unless explicitly configured to do so with "chkconfig".
What I'd like to be able to do, is to set a policy after system install,
and have all packages _obey_ this policy. :)
--
Stig Sandbeck Mathisen
ooo, shiny!
Attachment:
pgpRZ1IfrSmFX.pgp
Description: PGP signature