not starting a daemon upon installation
tldr: why is not having a daemon started on install so involved? Can't
there be a better way?
I'm hacking around an ansible playbook that needs to configure an etcd
The problem is that installing the package will automatically start the
daemon cluster in a "default" configuration.
That's a problem for me because etcd differentiates between starting the
cluster for the first time and starting it subsequentially. The first
time is special as it generates some internal state.
So I would like to control whether etcd - or for the matter any service
- is started upon package installation.
I imagine that this would be quite a standard requirement for
devops/configuration tools aka "please do not run and configure the
service for me because I want to do it precisely **this way**" (which is
kinda the point of configration automation).
Nota bene: that requirement does not criticise Debian packagers nicely
integrating all things - which is of huge value for the task.
When I duckduckgo "dpkg do not start service on install" first hit is
 which contains /absurdly involved/ suggestions to achieve "not
starting a daemon upon installation".
It /seems/ that the "official" way to achieve "not starting a daemon
upon installation" is to use `dpkg-divert` to overwrite `policy-rc.d`
with a script that exits with 101.
This to me seems again like a awkward, byzantine and brittle way to
achieve that goal. Also, the only canonical documentation of policy-rc.d
seems to be
/usr/share/doc/init-system-helpers/README.policy-rc.d.gz, which is quite
cryptic, contains no examples and contains "rc.d" in its name in a world
where systemd is the default, which makes me doubt whether all packages
using systemd will respect policy-rc.d...
So I'm wondering:
* is this really the official (twisted ?8-o) way to solve the problem of
not starting a daemon automatically upon installation?
* why was such an involved method chosen, instead of say setting an
environment variable DPKG_DONT_START_DAEMON or such?
I'm writing to d-d because I think this is a fundamental distro problem
that's worth a thought/discussion/improvement.