Devuan us a separate Debian with its own repositories (and presumably many packages patched to improve systemd-less life), while this is just replacing Systemd with OpenRC on a Debian system, while keeping Debian repos etc.
You're going to have to make a separate repo for everything anyways, because you'll have to change all the init scripts and whatnot that get supplied with programs... well, unless you install both and just leave the useless systemd files laying around forever.
My /usr/lib/systemd takes 6.4 megabytes, so I think I could live with that overhead. Or I suppose just delete them manually.
What would actually be useful would be a generic OpenRC wrapper that would ingest those service files and provide traditional start/stop interface for them.
You mean the inverse of systemd.generator? Probably wouldn't be hard to make, but you'd have to be pretty committed to your init system to not just write the script by hand...
Hmm, I perhaps didn't quite catch this. I thought having a generator would let you be less committed to it, as you wouldn't need to manually write all the init scripts you need.. ?
Writing a basic init script is less intensive than having to learn the entire "schema" for both script formats, which you'd probably want to know if you were writing the generator.
Well - it is an alternative to debian and in many ways is debian. But the counter-question is: why should debian users HAVE to use systemd? This is a much more fundamental question. Devuan solved it via forking. I think the proper way to handle this is to be able to offer both. I think gentoo went that approach. Debian went the "my-way-or-the-highway" route, which objectively is worse, even if understandable (less to maintain; see LFS/BLFS submitting to systemd finally in 2026: https://old.reddit.com/r/Gentoo/comments/1qy4xsc/might_gento... and https://www.phoronix.com/news/LFS-Dropping-SysVinit)
FWIW, debian did the gentoo approach for years. I used to run debian with OpenRC during a time when systemd was already the default. It and other init systems remained fully supported by the distro for quite a while.
Eventually, the pain of supporting everything became too much and debian did go with "my way or the highway", which I supported at the time and still do. I have no idea how that could be "objectively worse", it's very obviously a tradeoff to me. If your packages have to work on any init system, they can not benefit from any particular init system's features and have to work with the lowest common denominator. Every service has to hack around the lack of working state management with pidfile hacks and such.
In my opinion, it's better for a distro to pick any single init system than to try to support them all by limiting all packages to SysV style init scripts. Yes, user choice is important, but that can and does happen via distro choice. Alpine or Devuan are right there if you need them. Linux is fragmented enough, we don't need every distro to be a microcosm of the fractured overall Linux landscape.