I received a bug in OpenRC, #591388, which pointed out that OpenRC had a dependency on || ( sys-apps/sysvinit sys-process/runit ). The issue with this is it could leave systems unbootable if runit was emerged and sysvinit was not in the world file and depclean was run. I dropped the dependency on runit for 0.22.x, but that now means that since systemd blocks sysvinit OpenRC cannot co-exist with systemd. Does systemd have file collisions with sysvinit? If not, it seems that systemd should not block sysvinit. Thanks, William
I added back the dependency on runit in 0.22.1, but I still think we need to figure out why systemd blocks sysvinit.
(In reply to William Hubbs from comment #0) > > Does systemd have file collisions with sysvinit? If not, it seems that > systemd should not block sysvinit. > My understanding is that it only blocks on USE=sysv-utils. When this is set the ebuild installs symlinks for the files: "halt poweroff reboot runlevel shutdown telinit init." This is for backwards-compatibility with scripts/etc that expect these files to be present for systems that don't have sysvinit installed (and it also allows booting systemd using just "init"). I believe that systemd maintains a mostly-compatible interface with the sysvinit-supplied binaries so they work when systemd is PID 1. So, I think this is mostly-appropriate. If we get openrc out of @system we could have it block on this USE flag for systemd, since systemd can run fine either way, but openrc can only run if sysvinit implements these binaries. The default for systemd is to just run with sysvinit also installed. Note that it isn't a strict requirement, you can use systemd without USE=sysv-utils and without sysvinit installed, but then any scripts that call shutdown/etc will fail.
As Rich said, systemd only blocks sysvinit when the sysv-utils use flag has been enabled.
