> Now, it would be technically possible to replace *systemd* in base with a > generic "init-system" which could be provided by both *systemd* and *openrc*, > but that would make things much more complicated and *much* more effort to > maintain. Packages don't have a dependency on systemd because they need an init system. They have a dependency on systemd IPC interfaces and/or libraries not provided by openrc. If they depend on systemd without needing something like this, it's a (very minor) bug to report. Supporting alternative implementations of those interfaces (like Debian's systemd-shim) would mean a lot of extra work across the distribution. Arch supports one specific /bin/sh implementation, one standard C library, one standard C++ library, one C++ exception model, one toolchain for building the system, etc. It also tends to only support one specific implementation of a command-line utility as the main tool and others have to be namespaced. Packages like util-linux/coreutils aren't split into little pieces and there's no equivalent to update-alternatives. Sure, packages like musl, libc++, libc++abi and busybox are in the repositories but not in a way that can actually replace anything in the base system, it just lives alongside it without being used by any other packages. Arch only ever supported one init system until the transition period to systemd where it supported two. The old initscripts adopted systemd utilities like systemd-tmpfiles before going away anyway, and the old scripts were still supported. It was convergence to a single supported init system rather than two choices for the base system living alongside each other. Making technical decisions and then going through with them with proper integration into other packages is the only way that things are going to be polished. The alternative is a *lot* of extra complexity, development effort and bugs.
Attachment:
signature.asc
Description: OpenPGP digital signature
