Bug#949690: debian-policy: "service unit should have the same name as the package" seems too strong

[Simon McVittie]

Package: debian-policy
Version: 4.5.0.0
Severity: minor
X-Debbugs-Cc: systemd at packages.debian.org

If a package has a single system service with a systemd service unit,
and the system service's name does not match the package's name, current
Policy implies that this is probably a (non-RC) bug.

I think that's too strong. In particular, because the name of the service
unit is part of the "API surface" of the system service, aligning the
name of the service unit with the name used by upstream is usually
more important than aligning it with the name of the Debian package,
unless the name used by upstream results in conflicts or is otherwise
poorly-chosen. This is analogous to the names of executables in the PATH
and the SONAMEs of libraries, both of which we try not to change.

For example, flatpak contains the flatpak-system-helper.service unit
(not flatpak.service). I don't think that should be considered to be a
bug in flatpak: there is no system service that can/should be called
"the Flatpak service", only a system service that implements a small
non-essential part of flatpak (the ability for a suitably privileged
user to install Flatpak apps and runtimes system-wide), so it would be
misleading to have a flatpak.service unit.

The one time it would be a bug for the systemd service unit not to match
the package's name is when the systemd service unit needs to shadow a
pre-existing init script, and the init script was named according to
the Policy suggestion that its name should match that of the package.
In this case, I think the right thing to do is to add an alias (symlink),
similar to what was done in gdm3:

- /etc/init.d/gdm3 is a regular file
- /lib/systemd/system/gdm.service is a regular file
- /lib/systemd/system/gdm3.service is a symlink to gdm.service

However, I don't think this should apply to all single-system-service
packages, only those with pre-existing init scripts: it would be silly to
require flatpak to contain a symlink
/lib/systemd/system/flatpak.service -> flatpak-system-helper.service.

Flatpak's system service is started on-demand via D-Bus activation,
not on boot, so it never had a corresponding LSB init script. Strictly
speaking, if it had been started on boot and hence needed a LSB init
script, Policy version 4.4 and older would have implied that it was a
bug for the init script not to be named /etc/init.d/flatpak, which I
think would also have been too strong. However, LSB init scripts don't
have quite the same "it's API" argument as systemd services, because
they have historically been extremely distro-specific - indeed, one of
systemd's goals was to encourage service units to be provided by upstream
developers and shared by all distros, unlike LSB init scripts.

    smcv