It's silly that certain daemons check for a default settings file to decide if an execution is permitted rather than skipping that logic and defaulting the service off until either user intervention provides sane operating defaults, or the defaults are known to be sane otherwise.
I agree that a switch should be included with the package managers, but I also believe that the package managers should look for a switch from the package maintainers as well.
"areDefaultsSane = 0" should require user intervention to start after install and would be intended for things like insecure network daemons or daemons that control thermals/power/otherwiseImportantThings, whereas things that flagged "areDefaultsSane" as true would be started without intervention, this being intended for things like pulse.
things like thinkfan (a cpu/fan manager for linux) include "run_at_start = False" in the /etc/default file and things like that, but it feels woefully inadequate to rely on the package itself to check for something potentially mean when the environment could handle it in a standardized way, perhaps within whatever metadata is included in the deb file rather than the packages' included /etc/default/? (disclaimer: I don't know how deb files are put together)
Putting it in the metadata wouldn't help, since the point is to be mutable, that is, to allow the admin to switch the default to "run on startup".
> POLICY-RC.D Policy layer (/usr/sbin/policy-rc.d) interface:
> Most Debian systems will not have this script as the need for a policy layer is not very common. Most people using chroot jails just need an one-line script which returns an exit status of 101 as the jailed /usr/sbin/policy-rc.d script.
I think, however, that the point that the parent comment was trying to make was that it'd be convenient if this was a switch to apt-get. After all, if you are just looking to install one additional daemon on a running system, it'd be a whole lot easier if you could:
# apt-get install --no-start-daemon example
than to have to activate a policy script which you might forget to remove or deactivate.
However, in the file I mentioned above, the next line says:
> The /usr/sbin/policy-rc.d file must be managed through the alternatives system (/usr/sbin/update-alternatives) by any packages providing it.
So maybe one solution is to create your own script to manage it.
In fact, your script could even be a wrapper for apt-get. To be totally transparent in day-to-day use, you could then make apt-get be an alias for your wrapper script.
Your wrapper then:
1. Activates the policy.
2. Calls the real apt-get.
3. Deactivates the policy.
- more daemons (eg, puppet) ought to be "off" per default when it doesn't make sense
- apt-get should provide a switch to prevent newly-added daemons from starting, which could be used by provisioning systems
But saying that "daemons should never start at install" is silly.