Luca Boccassi <bl...@debian.org> writes: > 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. The mass bug filing happened, and although there were some objections on debian-devel, I don't think any of them were blocking. Specifically, I did not see anyone present a concrete plan for how to keep the systemd unit generator or some equivalent alive, and given that systemd upstream is dropping support for this feature, I believe that's the only way for this change to not be effective mandatory. Therefore, I think the time is ripe to proceed with this Policy change. I took a detailed look at this part of Policy today, and the whole system service section needs serious work. I believe the instructions it currently provides for constructing package maintainer scripts won't actually work with a current Debian system, and most Debian packages are technically violating the current Policy because it hasn't been updated for how systemd units work today. I started on overhauling that section, but it became clear that this is going to be a larger project with some potentially controversial decisions, so I'm going to open a new bug about that so that we don't block this change on that work. I made the following changes to your last diff: * Move the "should" about integrating with service management to the parent section. * Explicitly say that systemd is the default init system and service manager (it feels like we should say this somewhere, and I don't think we already do). * Add an explicit exception for packages intended only to support alternate init systems. (As an obvious example, sysvinit isn't going to ship a systemd unit, nor should it.) * Delete the paragraph suggesting that packages without systemd units should write an init script, since this will no longer accomplish the goal of getting that system service to work with systemd and therefore no longer seems to serve a purpose. Here is what I came up with. I think it is ready for seconds or objections. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
>From 474a9f4c74bc2c3a1d162de33e377a3585e641af Mon Sep 17 00:00:00 2001 From: Russ Allbery <r...@debian.org> Date: Sat, 9 Sep 2023 18:39:16 -0700 Subject: [PATCH] systemd unit files are now a must systemd is dropping support for the generator that allows it to automatically create units for init scripts. As a result, all packages that want to integrate with systemd service management must start shipping systemd units. State that arranging for services to be automatically started or stopped is a should, but if the package wishes to do that, a systemd service unit is a must unless the package is only intended for use with alternate init systems. Avoid saying that systemd uses /etc/rcn.d links to determine service ordering. --- policy/ch-opersys.rst | 35 ++++++++++++++++++++--------------- 1 file changed, 20 insertions(+), 15 deletions(-) diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst index 207b3c0..bee16f2 100644 --- a/policy/ch-opersys.rst +++ b/policy/ch-opersys.rst @@ -323,20 +323,25 @@ which try to write to a home directory will fail to build. Starting system services ------------------------ +Debian packages that provide system services should arrange for those +services to be automatically started and stopped by the init system or +service manager. This section describes how that is done. + .. _s-services-intro: Introduction ~~~~~~~~~~~~ -Packages that include system services should 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. +The default init system and service manager in Debian is ``systemd``. +Packages that wish to automatically start and stop system services must +include ``systemd`` service units to do so, unless the service is only +intended for use on systems running alternate init systems. See +:manpage:`systemd.service(5)` for details on the syntax of a service unit +file. -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. +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. 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 @@ -345,13 +350,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 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. The sections below describe how to write those scripts and configure those symlinks. -- 2.40.1
