On Tue, 2020-03-10 at 18:48 +0100, Simon Richter wrote: > Hi, > > On Tue, Mar 10, 2020 at 03:50:42PM +0000, jnq...@gmail.com wrote: > > > - the 'move start-stop-daemon' trick is the old-old solution, kept > > around because some packages failed to get on board with the > > policy- > > rc.d solution, and could be removed from things like > > debootstrap/live- > > build if and only if at some point in the future there was > > certainty > > that there were no such packages left. > > It is a bad hack, but it catches a few instances where people have > been > following very old packaging guides. Such packages likely don't exist > anymore in Debian, but the Debian tools are often used outside it, > especially in companies building embedded systems. > > Removing this hack would not affect Debian, but it might break some > users' > setups, so it's left in. > > > - the policy-rc.d solition is the old solution, kept around > > because > > systemd use is not quite 100%, though I'd expect and home that all > > packages are compatible by now, though systemd has a compatibility > > mechanism relating to policy-rc.d to work with users of that. > > Please disregard the statistics on systemd usage -- there is no > accurate > way to track installations because the vast majority of machines > don't > report back to Debian, and with containers, the question of what > counts as > a Debian installation is rather muddy anyway. > > The policy-rc.d interface is not an official interface according to > Debian > Policy, but it is used by invoke-rc.d, which is listed in Policy as > the > appropriate way to invoke an init script from a maintainer script, so > "support" is widespread. > > With systemd, a lot of these issues do not exist in the first place, > as no > systemd is running inside the chroot, so there is no mechanism to > start > services through systemd during debootstrap. > > Historically, the requirement to start daemons after installation is > older > than debootstrap and the idea of installing packages into a chroot. > Before > the current debian-installer, the installation system extracted a tar > file > into the target file system, made the system bootable and > installation then > proceeded from there. Maintainer scripts were seldom run inside a > chroot, > and those few that were had special checks. > > > From a debootstrap/live-build perspective, policy-rc.d is the only > mechanism that really matters, because it is respected by those > packages > that use a mechanism to start a daemon that actually works during > debootstrap time. > > > - 'systemctl mask' is the modern systemd solution. the best > > solution > > for users if they have systemd. probably pointless though for > > debootstrap/live-build use if they're having to keep policy-rc.d > > support and even start-stop-daemon support around anyway after all > > these years. > > "systemctl mask" does something else though: it disables a specific > service > across reboots by hiding it from systemd, while policy-rc.d asks to > be > consulted for every action. After installation, when the policy > script is > removed, its effect is gone, but masked services remain disabled. > > The equivalent of "systemctl mask" in the init.d world would be > "update-rc.d package defaults-disabled", as described in Debian > Policy > section 9.3.3.1. > > The systemd compatibility layer for policy-rc.d is not used for > bootstrapping, but to remain compatible with setups that use this > mechanism > at runtime to integrate with some site-wide configuration framework. > > Simon >
interesting. thankyou. :)