Cfrgtkky

I've created a deb package which installs a service.

On our embedded devices, I want this package to automatically enable the service. On our developer workstations, I want the devs to systemctl start foo manually (it's a heavy service and so it just consumes resources if run all of the time on a desktop environment).

How can I go about prompting the user for their decision during apt-get step? Is that the best solution?

Note, I've created the package using dh_make and debhelper and enabled it with:

%:

    dh $@ --with=systemd



override_dh_systemd_enable:

    dh_systemd_enable --name=foo foo.service

You can use systemd presets to affect whether a systemd service will default to being enabled or disabled at installation time.

The Debian presets default to enabling all services as they're installed, so you only need to ship a preset to the development workstations (the default behavior matches what you want to happen in production), by shipping a file such as /etc/systemd/system-preset/80-foo.preset containing a line that says

disable foo.service

If you manage your developer workstations using a system such as Puppet, Chef, Ansible, etc., you can use them to ship such a systemd preset configuration, that should make it easy for you to apply the policy to developer workstations only and not production machines.

Your .deb package should use the systemctl preset command to enable the service, since that command will respect the preset configuration. I'd expect the macros in deb-helpers (such as dh_systemd_enable) would do that already, but check your postinst script to make sure that's the case.

See the man page of systemd presets and systemctl preset for more details.

If you want to prompt the user during installation, you should use debconf. This has a number of advantages, even if you’re not in a context where Debian Policy is relevant: it provides a consistent end-user experience, with support for a variety of frontends; it supports different “levels”; it supports pre-seeding. Pre-seeding means that the package can be pre-configured, in which case it won’t prompt at all. The different levels mean that a prompt can be set up to only show in certain circumstances; you could then have the package install without prompting by default (for your embedded targets), and instruct your developers to set up their frontend appropriately when installing the package so that they see the prompt.

However, I think it’s better to avoid prompting altogether when possible. This is especially true for services which have other ways of dealing with end-user preferences, and where dealing with user preferences complicates the maintainer scripts (see the generated scripts in your package, they already deal with a number of subtle issues, using deb-systemd-helper — you’d have to replicate all that, with your preference handling on top).

If your developers never need to run the service, they can mask it before installing the package, and the service will never be enabled:

sudo systemctl mask foo

If your developers sometimes need to run the service, using the systemd unit, they can disable it after installing the package for the first time, and subsequent installs will remember this:

sudo apt install foo

sudo systemctl disable --now foo

The default would then be to enable the service.