[nubinetwork]

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.

[_flux]

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.

[nubinetwork]

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...

[_flux]

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.. ?

[nubinetwork]

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.

[_flux]

Yes, but one only needs to write it once, and then everyone could use it. It could probably even be packaged as an official Debian package.

[simoncion]

> Yes, but one only needs to write it once...

...and then keep up with behavioral changes that the Systemd Project people introduce and load-bearing bugs that services end up relying on for lifecycle management.

OpenRC service files are easy to write, and their schema is far far simpler than that of Unit files. [0] It's really not worth the effort to write and maintain an converter, if for no other reason than you need to understand the semantics of both systems' service files to double-check the results of the converter.

[0] <https://news.ycombinator.com/item?id=48717056>