Bug#1150223: Please drop the Conflicts on insserv and startpar from systemd-sysv

[Johannes Schauer Marin Rodrigues]

Package: systemd
Version: 262-1
Severity: normal
Tags: patch
X-Debbugs-Cc: debian-hurd at lists.debian.org, debian-init-diversity at chiark.greenend.org.uk, werdahias at riseup.net, mark at hindley.org.uk

Hello systemd maintainers,

TLDR: update-rc.d in unstable and testing ignores the presence of insserv when
systemd is installed. Please drop the Conflicts on insserv from systemd-sysv as
the conflict is no longer needed and poses problems for maintainers of init
systems other than systemd. Please also consider dropping the Conflicts with
startpar.

systemd is Debian's default init system. It is working well on Linux and I have
it running on the machine I'm typing this message on. Because it's the default
init system it is also installed on our CI systems like salsaci or the
autopkgtest runners.  For those of us who are interested in other init systems
(my own motivation is GNU/Hurd where systemd does not work), the Conflicts
relationship of systemd-sysv with insserv poses a problem because we cannot
install insserv without removing the init system of the machine. This matters
because even though I'm interested in different kernels, I still would like to
be able to carry out my work on Linux. It matters outside of my work
environment because our test infrastructure is running Linux and systemd.

The Conflicts relationship was added as part of the solution for bug #1072562
because update-rc.d wrongly runs it even on systems which use systemd to boot.
Since the resolution of #1141215, update-rc.d no longer interacts with insserv
on systems which are using systemd as init.

I propose the following patch to src:systemd:

--- a/debian/control
+++ b/debian/control
@@ -148,10 +148,9 @@ Conflicts: sysvinit-core,
            initscripts,
            orphan-sysvinit-scripts,
            sysv-rc,
-           insserv,
-           startpar,
            bfh-container (<< 20211009-22~),
            molly-guard (<< 0.8.2~),
+Breaks: init-system-helpers (<< 1.69+nmu1),
 Replaces: sysvinit-core,
 Pre-Depends: systemd
 Depends: ${misc:Depends},

I used the Breaks relationship to make sure that systemd-sysv with the
Conflicts on insserv and startpar removed is not accidentally installed on
systems with an older version of init-system-helpers.

Removing the Conflicts would allow autopkgtests for packages like startpar,
runit, openrc and insserv itself to work on debci as well as salsaci. It would
also make it easier to create Hurd chroots on Linux without the inconvenience
of having to create a chroot inside a chroot even though the code is already
running in a disposable VM (but that one runs systemd, for example on salsaci).

Right now, the autopkgtest of, for example, startpar fails like this:

--%<--------------------------------------------------------------------------
  Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming.
  The following information may help to resolve the situation:
  
  The following packages have unmet dependencies:
   satisfy:command-line : Depends: insserv but it is not going to be installed
                          Depends: startpar but it is not going to be installed
  E: Unable to satisfy dependencies. Reached two conflicting assignments:
     1. insserv:amd64 is selected for install because:
        1. satisfy:command-line:amd64=1 is selected for install
        2. satisfy:command-line:amd64 Depends insserv
     2. insserv:amd64 is available in version 1.27.0-1
        but none of the choices are installable:
        - insserv:amd64=1.27.0-1 is not selected for install because:
          1. systemd-sysv:amd64 is selected for install
          2. systemd-sysv:amd64 Conflicts insserv
  testsuite            FAIL badpkg
  blame: startpar
  badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U.
  autopkgtest [05:51:07]: @@@@@@@@@@@@@@@@@@@@ summary
  testsuite            FAIL badpkg
  blame: startpar
-->%--------------------------------------------------------------------------

The autopkgtest works fine on a system without systemd-sysv installed but since
systemd is our default init system, the package is installed in the autopkgtest
runners on ci.debian.net as well as salsaci.

Since support for LSB initscripts got removed from systemd and since
update-rc.d now no longer considers insserv on systems with systemd as init, we
wonder which technical reason remains for the Conflicts relationship which got
added to systemd-sysv as the solution to bug #1072562. This issue has more
discussion in bug #1132024 where I propose to add the insserv-bin binary
package which ships the insserv executable outside of $PATH. But we consider
this solution the last resort which only should be taken if there are technical
reasons against dropping the Conflicts relationship from systemd-sysv.

To back up my request with data I created [1]. The script processes all
packages shipping files in /etc/init.d/ and installs them one-by-one into a
fresh chroot created with mmdebstrap in two different scenarios. In one of
them, /usr/bin/insserv is present in $PATH. The resulting tarballs are then
compared and the expectation is, that the system after package installation are
equal independent on whether /usr/bin/insserv was present or not. I'm not
really sure what problem I should be looking out for.  The biggest problem is
that some maintainer scripts write unreproducible data into /etc which makes
comparison difficult. I also need a stronger computer because salsaci is only
able to process 128 packages within the allowed 4 hours of runtime, so it only
gets until console-setup-linux.

[1] https://salsa.debian.org/josch/insserv-systemd-coinstall/-/blob/main/run.sh

If systemd maintainers can give me some input on what problems they expect to
happen with the insserv binary in $PATH on systems with systemd as init, I'd be
happy to perform the relevant archive-wide tests and fix issues accordingly.

Same goes for startpar. We wonder which technical reason exists today for
systemd-sysv to conflict with it. Was it added to the Conflicts field just as
"collateral damage" when insserv got added? We ask to drop the Conflict unless
there exists a technical reason against doing that.

We hope that by removing the Conflicts relationship on insserv and startpar we
can improve the co-existance of systemd, insserv, runit, (soon) native openrc
and maybe others in the future and reduce the road-blocks which currently make
life difficult for those of us who are interested in other kernels than Linux
and other init systems than systemd.

Thanks!

cheers, josch