Bug#944801: debian-policy: must all inits support /etc/insserv/override & /usr/share/insserv/override

[Russ Allbery <rra@debian.org>]

Ansgar <ansgar@43-1.org> writes:

>>> 9.11 states:
>>> 
>>> +---
>>> > Alternative init implementations must support running SysV init
>>> > scripts as described at System run levels and init.d scripts for
>>> > compatibility.
>>> +---

> Thinking a bit more about this, I think this requirement should just be
> removed from Policy.  It should be left to the individual communities
> interested in a particular init system how much compatibility with
> sysvinit is useful for them.

I think the current approach in the entirety of 9.11 no longer makes
sense, but there are two possible alternative approaches and which to pick
will depend on the results of the current GR.  Therefore, I think we
should for the results of the GR rather than doing work on this right now.

The two alternatives I see are:

1. Some GR option saying that systemd is the only supported init system
   wins.  In that case, we're going to be deprecating init scripts since
   the integration proporties of unit files are so much better, so we'll
   be making other changes to Policy to document systemd units as the
   preferred syntax for configuring services and everything 9.11 currently
   says should be deleted.  (We probably still want a section on
   alternative init systems, but it would be much different.)

2. Some GR option saying that we want to continue to maintain init scripts
   for compatibility with other init systems wins.  In this case, I think
   we should document the common init script syntax used for compatibility
   purposes along with whatever rules the GR indicates we should have for
   when an init script alongside a systemd unit is required.  Then, I
   think we should rephrase 9.11 to instead say that services are
   configured with either unit files or init scripts and an alternative
   init system therefore would need to handle one or the other or it won't
   be able to properly boot Debian.  (Which does not necessarily mean that
   it would violate Policy requirements; there's nothing wrong with
   packaging init systems intended for use inside containers or other
   special-purpose environments that do not need to support arbitrary
   Debian packages.  But any alternate init system should make clear which
   of those use cases it's aiming at.)

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>