Quoting alecfeldman@??? (alecfeldman@???):

> First of all, I want to thank the developers for the efforts to
> continue debian without "systemd creep". I've experimented with the
> distribution on and off, but there's one big turnoff for me currently
> that I don't think would take an enormous amount of effort to change:
> sysvinit. While it does work perfectly fine on its own, I prefer
> openrc, and runit even more so. While they do work in Devuan, they
> require sysvinit as a "backend". In Devuan ceres and up, openrc 0.25
> provides openrc-init and no longer relies on sysvinit-core. In fact,
> it can be removed entirely (I have an addiction to removing everything
> I don't want to use). However, openrc-init boots openrc directly and
> skips the /etc/inittab file, so it won't start the gettys. All that
> would be needed to fix this is a separate getty service package.

You're right, of course. (For clarification purposes, I'm not a Devuan
project spokesperson of any kind, just another interested user and
longtime sysadmin.) It would be cool if that were done, and maybe the
maintainers will figure out the best way to do that. Part of the point
I wanted to make, here (bearing in mind that I'm speaking only my own
view), is that Devuan needs to be mindful of priorities and has
necessarily limited volunteer effort. For better or worse, _if_ I
understand correctly, for now Devuan's primary delivery target for
current and future releases involves SysVInit.

As it hapens, I personally share your liking for OpenRC over SysVInit,
and respect runit based on readings but haven't experimented with it as
Steve Litt has. But my point is that, if I guess correctly, in the
short term there may not be enough time/effort available to build in
fully packaged, optimally architected implementations of those two init
systems.

The other immediate thought I had, and I'll just throw this out as a
slightly rhetorical question: Is it so bad to retain the PID1-process
fragment of SysVinit, e.g., as what runs the OpenRC init system? Seems
to me, it's the part of SysVinit nobody has any significant problem
with. It's not unreasonably complex, it's not notably buggy, and it's
certainly not overfeatured.

I note with interest and appreciation your suggestions about how runit
might be provided in better built packaging, but will leave it to others
(such as my friend Steve Litt) to comment. Daniel's wording about a way
to extend these ideals into a framework for other init systems is
particularly cheering, so thanks for posting that.