Bug#934805: lintian: probably shouldn't emit package-supports-alternative-init-but-no-init.d-script for instanced systemd services (foo@.service)

[Simon McVittie <smcv@debian.org>]

Package: lintian
Version: 2.18.0
Severity: minor

Some packages contain "instanced" systemd units named like foo@.service,
which represent a family of possible systemd units foo@bar.service for
arbitrary values of bar. For example, quake2-server in contrib is one of
these: you can run any number of servers on different ports by creating
more than one configuration file and enabling multiple instances of
the unit.

This is not a feature that exists in LSB init scripts, so I don't think
maintainers can be expected to provide it. I can see two possible
improvements here:

- do not emit package-supports-alternative-init-but-no-init.d-script for
  foo@.service at all, on the basis that the feature does not exist in
  LSB init, so feature parity is not implementable

- do not emit package-supports-alternative-init-but-no-init.d-script for
  foo@.service if /etc/init.d/foo exists, on the assumption that
  /etc/init.d/foo is equivalent to one of the instances of foo@.service

If a package contains /etc/init.d/foo and foo@.service, then it should
likely also either contain foo.service (e.g. quake2-server follows this
pattern), or "mask" foo.service by making it a symlink to /dev/null to
avoid both /etc/init.d/foo and instances of foo@.service being invoked
under systemd.

Thanks,
    smcv