Package: debian-policy Version: 4.5.0.0 Severity: minor X-Debbugs-Cc: syst...@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