Some have asked about technical layout variants: What would you expect from freedom of init choice? A half way means to offer at least one 2nd choice for pid1 and a 2nd init system and keep systemd for the other tasks it tries to serve. This would still not offer a true choice for the additional systemd parts if you don't trust or simply don't want anything systemd related on your system or just want the full freedom to use tools by your own choice.
To achieve such a full systemd replacement as some desktop and userland applications depend on functions you cannot split out of systemd anymore there's need to add (e)udev+elogind packages to the repos. I see two ways an Arch based distro can achieve full (systemd-less) freedom: 1) go with the current repo layout and use extensively libprovides and virtual providers and split systemd further down into useful parts and make it less monolithic allowing user to choose desired parts or not. Then make anything possible only depend on provided libs/virtual providers that can be served by replacements tools as well. 2) add a replacing [nonsystemd] repo above [core] to pacman.conf that users can enable if desired. Packages in the nonsystemd repo provide some of the systemd functions. The systemd and core packages probably wouldn't need major changes. Either choice would need a decision whether all service initscripts get packaged into one e.g. openrc-service-scripts package or if each service package ships the scripts for all supported init choices in one single package or split out the systemd/initscripts into subpackages. If this is still Arch and KISS is actually questionable but being forced to have full systemd on my system doing its magic isn't KISS either and I'm afraid systemd is going worse over time (just my opinion and expectation). Maybe there's some middle way to bring down systemd to its essential parts and leave it up to AUR and custom repos to build something on top of that. While I've received some support here on the list and more off the list it seems a majority of the core team is against adding some init freedom support at this time. -Andy
pgpfmOG4Ym4JP.pgp
Description: Digitale Signatur von OpenPGP
