|
|
|
|
|
|
by tkinz27
3290 days 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. |
|
|
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/
* 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#...
* 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.