Russ Allbery wrote: > If we're not, we should unambiguously free people from doing > additional work that they don't want to do and can't test easily
I really appreciate your mail, and I think this point is entirely true. I also feel there's a key detail to add here, in that this isn't just about not having to do extra work to support sysvinit. This isn't just about not putting extra work on package maintainers rather than on the maintainers of non-default init systems. It isn't *just* that sysvinit support requires writing and maintaining an init script. This is also about allowing package maintainers (and upstream developers) to use the capabilities of systemd, which many other distributions are using to the fullest, but which Debian has been prevented from using precisely because the ongoing threat of an RC bug for sysvinit support (or worse, a hundred-message energy-sapping mail thread) prevents people from taking full advantage of those features. Today, people can't just use systemd-tmpfiles as their means of creating files at startup, because they have to have a fallback for the non-systemd case. Today, people can't use systemd persistent timers in place of cron (and in place of anacron's "wake up periodically" approach). You have to have a cron job as well, and there's no good mechanism to automatically prevent a cron job from running when running systemd and a corresponding timer exists, so systemd systems would still have to have a pile of cron jobs that wake up just to say "oh, I'm on systemd, exit". Systemd user sessions, socket activation, sysusers, dynamic users, systemd-homed, temporary directory setup, transient units, anything talking to the slice or control group APIs, containerization, firstboot, systemd's whole "preset" system-wide configuration and policy mechanism for admins to say "what services do I want launched when installed and what services do I want to leave stopped until I configure them", "stateless system" capabilities, and I'm probably forgetting another dozen. Note: I'm not trying to say "we should wholeheartedly adopt every one of these technologies"; please don't make this thread about that, or any one specific technology. The issue is that we don't even have the option of *considering* most of these technologies in the current environment. Even if Policy changed tomorrow to have a full "unless you're using capabilities that alternate init systems don't have" clause, people would still be afraid of using those capabilities or merging patches that do so, lest their work become the subject of a giant flamewar. We should get to a state where people building something interesting using these capabilities and technologies can expect useful feedback, and potentially excitement and collaboration, rather than flames. I think we need to move past the framing of "people don't want to write init scripts"; this is also about being unable to use a decade of additional capabilities that go far beyond sysvinit. The net result of the decision years ago was, effectively, "we can use systemd as 'a better sysvinit', but we can't use any capabilities that go substantially beyond sysvinit". If we're going to have a GR, part of the goal should be to either confirm the current state that we're never moving very far past the capabilities of sysvinit even when most people don't run it, or that we're allowed to use the full capabilities of our default init system even when there's no equivalent elsewhere. - Josh Triplett