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