Integration with systemd
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
Reply to: