4 ms·

- HEADLINE: Not start services by default - DESCRIPTION: If I installed e.g. postgresql I would prefer it not starting automatically by default. I would rather

- HEADLINE: Not start services by default - DESCRIPTION: If I installed e.g. postgresql I would prefer it not starting automatically by default. I would rather like a message: If you want x to start on boot, type 'update-rc.d enable x' - DISTRIBUTION: (Optional) [stable] - ROLE/AFFILIATION: (software dev, mostly web)

tkinz27 9y ago
I can't thumbs up this enough. Packages that start services when they are installed can cause so many issues between not giving the user the chance to fully configure them, to weird interactions with distributed applications talking to each other before all the configuration is ready. This is definitely one of the defaults that I think RPM gets right over debian packages.
- JdeBP 9y ago
  This isn't something that is inherent to Debian packaging. So it´s not an RPM/DEB thing at all. There was a proposal a couple of years back by one Debian member to do pretty much this, and buried somewhere on the Debian WWW sites there is an explanation by that person. Unfortunately, I mislaid the URL and have forgotten who it was. The essence, however, is to do as Gerrit Pape happens to have done all along with xyr Debian packages. M. Pape split them into daemontools and daemontools-run, runit and runit-run, and so forth. One package installs the softwares and the service definitions. The other package enables+starts/disables+stops the services. * http://smarden.org/pape/Debian/ http://smarden.org/pape/Debian/ * https://lists.debian.org/debian-devel/2012/06/msg00100.html https://lists.debian.org/debian-devel/2012/06/msg00100.html I do the same with my Debian packages. * http://jdebp.eu./Softwares/nosh/debian-binary-packages.html#Bundles http://jdebp.eu./Softwares/nosh/debian-binary-packages.html#... * http://jdebp.eu./Softwares/nosh/debian-binary-packages.html#run http://jdebp.eu./Softwares/nosh/debian-binary-packages.html#... The most oft-repeated complaints about the current system are that policy-rc.d requires that administrators have prior knowledge of the internals of a package, to know what services to whitelist/blacklist before installing the package and seeing what services it contains; and that both policy-rc.d and the general body of maintainer scripts in Debian and Ubuntu do not play at all well with systemd's own preset mechanism.
rlpb 9y ago
You can configure this behaviour today. Search for "policy-rc.d". IMHO, it's a bug in configuration management tools that they do not arrange this by default.
- Twirrim 9y ago
  deb/dpkg/apt is the only one I've seen which does this. All other distributions go for install only. Starting on install is more intuitive for people new to linux, but it's bad as an overall practice.
  - rlpb 9y ago
    I think Debian's rationale is that if a sysadmin interactively installs a package, then that sysadmin does so to get its primary service (if any) running, so packages should arrange this by default. > but it's bad as an overall practice. I agree with you, but only in the case of non-interactive use. Different use cases demand different defaults. Tooling should be able to make the appropriate distinction automatically. Currently, the tooling does not, but that (IMHO) is a design flaw in the tooling, which Debian does not produce. In the interactive case, I'm torn, but I do see the logic. In the general case, then, I maintain that tooling should use policy-rc.d to adjust the default as necessary, and that failure to do so is in the tooling, not in Debian.
    - dozzie 9y ago
      > I think Debian's rationale is that if a sysadmin interactively installs a package, then that sysadmin does so to get its primary service (if any) running, so packages should arrange this by default. Except that if a sysadmin installs a package that provides a daemon, this daemon usually needs to be configured first, so starting it with semi-broken config (and debconf-generated one is still semi-broken) is counterproductive.

tkinz27 9y ago

I can't thumbs up this enough. Packages that start services when they are installed can cause so many issues between not giving the user the chance to fully configure them, to weird interactions with distributed applications talking to each other before all the configuration is ready. This is definitely one of the defaults that I think RPM gets right over debian packages.

JdeBP 9y ago
This isn't something that is inherent to Debian packaging. So it´s not an RPM/DEB thing at all. There was a proposal a couple of years back by one Debian member to do pretty much this, and buried somewhere on the Debian WWW sites there is an explanation by that person. Unfortunately, I mislaid the URL and have forgotten who it was. The essence, however, is to do as Gerrit Pape happens to have done all along with xyr Debian packages. M. Pape split them into daemontools and daemontools-run, runit and runit-run, and so forth. One package installs the softwares and the service definitions. The other package enables+starts/disables+stops the services. * http://smarden.org/pape/Debian/ http://smarden.org/pape/Debian/ * https://lists.debian.org/debian-devel/2012/06/msg00100.html https://lists.debian.org/debian-devel/2012/06/msg00100.html I do the same with my Debian packages. * http://jdebp.eu./Softwares/nosh/debian-binary-packages.html#Bundles http://jdebp.eu./Softwares/nosh/debian-binary-packages.html#... * http://jdebp.eu./Softwares/nosh/debian-binary-packages.html#run http://jdebp.eu./Softwares/nosh/debian-binary-packages.html#... The most oft-repeated complaints about the current system are that policy-rc.d requires that administrators have prior knowledge of the internals of a package, to know what services to whitelist/blacklist before installing the package and seeing what services it contains; and that both policy-rc.d and the general body of maintainer scripts in Debian and Ubuntu do not play at all well with systemd's own preset mechanism.

rlpb 9y ago

You can configure this behaviour today. Search for "policy-rc.d". IMHO, it's a bug in configuration management tools that they do not arrange this by default.

Twirrim 9y ago
deb/dpkg/apt is the only one I've seen which does this. All other distributions go for install only. Starting on install is more intuitive for people new to linux, but it's bad as an overall practice.
- rlpb 9y ago
  I think Debian's rationale is that if a sysadmin interactively installs a package, then that sysadmin does so to get its primary service (if any) running, so packages should arrange this by default. > but it's bad as an overall practice. I agree with you, but only in the case of non-interactive use. Different use cases demand different defaults. Tooling should be able to make the appropriate distinction automatically. Currently, the tooling does not, but that (IMHO) is a design flaw in the tooling, which Debian does not produce. In the interactive case, I'm torn, but I do see the logic. In the general case, then, I maintain that tooling should use policy-rc.d to adjust the default as necessary, and that failure to do so is in the tooling, not in Debian.
  - dozzie 9y ago
    > I think Debian's rationale is that if a sysadmin interactively installs a package, then that sysadmin does so to get its primary service (if any) running, so packages should arrange this by default. Except that if a sysadmin installs a package that provides a daemon, this daemon usually needs to be configured first, so starting it with semi-broken config (and debconf-generated one is still semi-broken) is counterproductive.