Conditionally enabling systemd files through Debian packaging

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.

As @JdeBP and @sourcejedi point out, the Debian macros in deb-helpers (such as dh_systemd_enable) do that already, they invoke deb-systemd-helper which will use systemctl preset by default (with a small caveat that if you remove (but do not purge) the package, and later re-install it, it will then not enable the service, even if you remove the preset file.) See this comment in deb-systemd-helper's enable operation:

    # We use 'systemctl preset' on the initial installation only.
    # On upgrade, we manually add the missing symlinks only if the
    # service already has some links installed. Using 'systemctl
    # preset' allows administrators and downstreams to alter the
    # enable policy using systemd-native tools.

For more information on the systemd feature of presets, see the man page of systemd presets and of the command systemctl preset which implements it.

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.