Bug#911290: policy-rc.d is a bad interface, please replace it

[Wouter Verhelst]

Package: init-system-helpers
Version: 1.54
Severity: wishlist

Hi,

There are several problems with policy-rc.d as it stands now:

- It requires system administrators that want to use it, to drop a
  script in /usr/sbin, which is FHS-mandated to be the domain of the
  packaging system (this is filed as #375183)
- In some ways, it is too flexible an interface for configuring actions
  that should be taken. The number of possible actions that can
  reasonably be taken is not that large; it should be possible to
  enumerate them all, and create a declarative interface, rather than an
  imperative one, to configure what should happen upon a requested
  service (re)start from a maintainer script; a full script should not
  be required for most cases. In those situations where this might be
  desirable, a declarative interface could have a statement allowing to
  test whether a rule should be activated by running a small scriptlet.
- In other ways, it is too inflexible an interface. There is only one
  policy-rc.d, and it is not packaged; therefore, anyone who wants to
  (temporarily) suppress service (re)starts has to write a policy-rc.d
  script. Examples include:
    - debian-installer writes a policy-rc.d script so that packages that
      get installed during the initial installation run don't start their
      services. It removes this upon installation completion.
    - SteamOS, a Debian derivative, writes a policy-rc.d script so that
      automatic upgrades at shutdown time don't restart services (which
      would be stopped almost immediately after, anyway).
    - The "debuerrotype" script, which is used to produce the official
      Debian images on the docker hub, creates a policy-rc.d script:
  
      cat > "$targetDir/usr/sbin/policy-rc.d" <<-'EOF'
              #!/bin/sh

              # For most Docker users, "apt-get install" only happens during "docker build",
              # where starting services doesn't work and often fails in humorous ways. This
              # prevents those failures by stopping the services from attempting to start.

              exit 101
      EOF

  These uses of policy-rc.d can and will clash. For example, the SteamOS
  policy-rc.d script ended up not being active in practice, because it
  was written during installation time at a point in time where the
  debian-installer version of policy-rc.d had not yet been removed. When
  debian-installer then later tries to remove its version of
  policy-rc.d, it removes the SteamOS one instead, with disastrous
  results.

  It is true that the policy-rc.d interface makes it a requirement for
  any policy-rc.d script to be installed through the alternatives
  system. However, a) this does not happen in practice; and b) even if
  it did, that would not easily allow multiple such policies to coexist
  and be active at the same time. For instance, a SteamOS user might
  want to keep the default SteamOS policy in place (which only kicks in
  if the system is in the process of being shut down), but add their own
  policy for a handful of packages that they care about.
- It is not discoverable. On a default Debian installation, there is no
  policy-rc.d script on the system; it is only documented in the
  invoke-rc.d(8) man page (a script not meant to be invoked manually by
  system administrators, so they would not normally need to read it) and
  in </usr/share/doc/init-system-helpers/README.policy-rc.d.gz>. Both
  could be found by someone who knew it existed; but for someone who did
  not, it might as well not exist.

For these reasons, I would like to request that policy-rc.d as an
interface is replaced by a set of declarative configuration files, and
to have the directory where they should be written be on the system by
default.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, m68k, arm64

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE=nl_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages init-system-helpers depends on:
ii  perl-base  5.26.2-7+b1

init-system-helpers recommends no packages.

init-system-helpers suggests no packages.

Versions of packages init-system-helpers is related to:
ii  insserv  1.14.0-5.4+b1

-- no debconf information