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