Bug#941198: initscripts: packages should ship systemd units
On Fri, 01 Nov 2019 at 12:21:43 +0100, Ansgar wrote:
> Dmitry Bogatov writes:
> > Does it mean that lack of systemd unit file is RC-critical bug? Or I
> > will be able to waive it with "you are welcome to contribute a patch"
> > response?
I think in general the answer is that it should be a non-RC bug to have
an LSB ("sysvinit") init script /etc/init.d/foo without a corresponding
systemd service /lib/systemd/system/foo.service (but maintainers should
accept good patches).
Notable exceptions that shouldn't be considered to be bugs:
- if foo is provided in some other way on systemd systems, then the init
script should be masked (symlink
/lib/systemd/system/foo.service -> /dev/null), either by the package that
provides it (e.g. screen and sudo both do this), or by systemd itself
(as is currenly done for "core" init scripts in packages like sysv-rc
and x11-common; but perhaps responsibility for doing this should move
to the non-systemd package, coordinating that transition with the
systemd maintainers, now that systemd is the default and has been for
a while?)
- if foo is provided under a different name on systemd systems, then
/lib/systemd/system/foo.service should be a symlink to the
systemd name for it (udev.service -> systemd-udevd.service and
network-manager.service -> NetworkManager.service are good examples)
- packages that cannot be co-installed with systemd-sysv should get an
exemption from this, as the opposite of the rule that says it's OK that
systemd-cron doesn't have LSB init scripts :-)
> Or should we consider making shipping a sysvinit script, but no systemd
> unit a RC bug?
Not in general, I don't think, but there are certainly situations where
it should be made RC on a case-by-case basis:
- rcS scripts nearly always need a native systemd service, because the units
that systemd generates for LSB init scripts always end up in the
equivalent of rc2
- more generally, if the conservative assumptions that systemd has to make
about LSB init scripts result in broken behaviour in practice (notably,
apache2 in the initial jessie release had this problem) then the broken
behaviour might be a RC bug, to be fixed by either adding a native
systemd service (like apache2 in stretch) or carefully overriding some
aspects of the generated systemd service (like apache2 in jessie updates).
In this case I'd say the absence of a systemd service is not RC, but the
*practical effect of* the absence of a systemd service can be RC.
smcv
Reply to: