Package: debian-policy X-Debbugs-Cc: pkg-systemd-maintainers@lists.alioth.debian.org systemd upstream will drop support for the transitional sysv generator in the near future. The transition is long finished, it's been at least a decade, and it's time for the tail of packages still shipping only init scripts but not units to be updated. Tentatively this should happen within Trixie's development cycle. Of course it's free software and generators are not that difficult to maintain, so if someone wanted to lift the sysv generator out of the systemd repository and adapt it to be a standalone binary there's nothing stopping them. But I wouldn't want the systemd package to depend on such a backward compat tool, so packages needing this hyptothetical package should depend explicitly on it. This is just mentioned for completeness, it's been at least a decade and writing a unit file is beyond trivial so there shouldn't be any issue adding the few remaining ones. Once the policy is updated I plan to ask Lintian to bump the severity of the existing check: https://salsa.debian.org/lintian/lintian/-/merge_requests/407 Patch attached and pushed to https://salsa.debian.org/bluca/policy/-/commits/mandatory_units?ref_type=heads -- Kind regards, Luca Boccassi
From ea524f52d256e37b4e4747d7e6ac4f316c4805a8 Mon Sep 17 00:00:00 2001 From: Luca Boccassi <bluca@debian.org> Date: Sun, 25 Jun 2023 18:42:29 +0100 Subject: [PATCH] system services: make systemd units mandatory systemd upstream will drop support for the transitional sysv generator in the near future. The transition is long finished, and it's time for the tail of packages still shipping only init scripts but not units to be updated. --- policy/ch-opersys.rst | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst index 207b3c0..3134783 100644 --- a/policy/ch-opersys.rst +++ b/policy/ch-opersys.rst @@ -328,16 +328,12 @@ Starting system services Introduction ~~~~~~~~~~~~ -Packages that include system services should include ``systemd`` service +Packages that include system services must include ``systemd`` service units to start or stop those services. See :manpage:`systemd.service(5)` for details on the syntax of a service unit file. In the common case that a package includes a single system service, the service unit should have the same name as the package plus the ``.service`` extension. -If the package does not include a service unit (if, for example, no one -has yet written one), including an init script, as described below, to -start the service is encouraged. - Packages including a service unit may optionally include an init script to support other init systems. In this case, the init script should have the same name as the ``systemd`` service unit so that ``systemd`` will ignore @@ -345,13 +341,13 @@ it and use the service unit instead. Packages may also support other init systems by including configuration in the native format of those init systems. -If a service unit is not present, ``systemd`` uses dependency information -contained within the init scripts and symlinks in ``/etc/rcn.d`` to decide -which scripts to run and in which order. The ``sysv-rc`` runlevel system -for ``sysvinit`` uses the same symlinks in ``/etc/rcn.d`` to decide which -scripts to run and in which order at boot time and when the init state (or -"runlevel") is changed. See the ``README.runlevels`` file shipped with -``sysv-rc`` for implementation details. Other alternatives might exist. +``systemd`` uses dependency and ordering information contained within the +enabled unit files to decide which services to run and in which order. +The ``sysv-rc`` runlevel system for ``sysvinit`` uses symlinks in +``/etc/rcn.d`` to decide which scripts to run and in which order at boot +time and when the init state (or "runlevel") is changed. See the +``README.runlevels`` file shipped with ``sysv-rc`` for implementation details. +Other alternatives might exist. The sections below describe how to write those scripts and configure those symlinks. -- 2.39.2
Attachment:
signature.asc
Description: This is a digitally signed message part