Hello Wouter, Wouter Verhelst [2019-11-09 10:32 +0200]: > > Choice 1: Affirm Init Diversity > > > > Being able to run Debian systems with init systems other than systemd > > continues to be something that the project values. With one > > exception, the Debian Project affirms the current policy on init > > scripts and starting daemons (policy 9.3.2, 9.11). Roughly, packages > > should include init scripts to start services that are included. > > Policy notes that early boot services like those started from > > /etc/rcS.d may be tied closely to the init system in use. > > I don't see why this is relevant in the current discussion. > > My nbd-client package is one that is relevant here; it has a systemd > unit, and an rcS init script (which is then ignored by systemd). If this > choice wins, then init scripts remain mandatory. If you provide an rcS > init script, then systemd units are also mandatory.
IMHO early-boot services in rcS.d are one of the most important aspects of this entire discussion. Late boot services are generally easy, as the vast majority have simple dependencies and simple startup logic in the sense of how deeply they need to interact with the guts of the OS. Ignoring systemd features like privilege reduction/isolation/robustness, a systemd unit and a SysV script that uses /lib/init/init-d-script have roughly the same complexity. They are reasonably easy to test on both a systemd and a SysV init system, and it's the right thing to let them be maintained by the individual package maintainers. But this picture is entirely different in early boot (rcS.d, or sysinit.target): these have complex, brittle, and dynamic dependencies, are hardware/install type/configuration dependent, and require an integrative cross-package design, development, and maintenance. This is the part where SysV init scripts and distributed maintenance are desperately bad, and why a lot of configurations had been so buggy or impossible for many years. They suffer from imperative shell script hell and not enough machine readability/introspectability/uniformity to reason about or validate them. For these a distributed maintenance approach has been shown to not work well; integrating NetworkManager, LUKS, NFS, LVM, RAID, dynamic partition type detection, udev, X.org/wayland/login managers etc. needs to be a primary responsibility of the team that maintains the init system itself [1]. These need comprehensive system integration tests [2] with lots of different scenarios. This is the one thing in that GR that I have a strong opinion on (backed by doing *two* init system migrations in my life): Choice 1 is a non-starter if it mandates distributed SysV init script maintenance for early-boot services. If these are exept, and maintained/QAed by the corresponding init system, then Choice 1 is very sensible and practical. I wish that the GR text could expand on that a little bit, but I do appreciate that this quickly gets into the trenches of deep technical details. For now I interpret the last sentence as a sufficient exception (avoiding the word "loophole") for that scenario. > So this is not an exception to the rule? It just means you have more > work to do. What do you mean by "more work to do"? I. e. what and who? Thanks, Martin [1] That of course doesn't mean that the package maintainer doesn't have a say in that -- they absolutely do. But to a large degree they need to trust and defer to the maintainers of the init system. [2] autopkgtests can also do that -- I wish we had had what we have today in the upstart/early systemd times!
