... or implement a different init than openrc or runit? There are obstacles and growing where package dependencies require the user to choose (1 OpenRC 2 Runit) without an option for none-of-the-above.
Example:
# pacman -S rtkit
:: There are 2 providers available for svc-manager:
:: Repository system
1) openrc 2) runit
Package (17) Old Version New Version Net Change
system/artix-sysvcompat 0.3.9-1 0.06 MiB
system/dbus-openrc 20180429-1 0.02 MiB
system/elogind-openrc 20181210-1 0.02 MiB
system/eudev-openrc 32-6 0.03 MiB
world/kexec-tools 2.0.17-1 0.24 MiB
system/kmod-openrc 20180502-1 0.02 MiB
system/netifrc 0.6.1-1 0.36 MiB
system/openrc 0.41.2-1 2.19 MiB
system/opensysusers 0.5-1 0.05 MiB
system/opensysusers-openrc 0.5-1 0.02 MiB
system/opentmpfiles 0.2-2 0.05 MiB
system/opentmpfiles-openrc 0.2-2 0.03 MiB
system/dbus 1.12.12-1 0.01 MiB
system/elogind 241.3-1 3.11 MiB
system/libelogind 241.3-1 0.66 MiB
system/libeudev 3.2.7-4 0.18 MiB
world/rtkit 0.12-1 0.14 MiB
Total Installed Size: 8.26 MiB
Net Upgrade Size: 7.19 MiB
:: Proceed with installation? [Y/n] n
or by pressing option 2 the following:
Package (14) Old Version New Version Net Change
system/artix-sysvcompat 0.3.9-1 0.06 MiB
system/bootlogd 2.89-2 0.05 MiB
system/dbus-runit 20180621-1 0.03 MiB
system/elogind-runit 20180621-1 0.03 MiB
system/eudev-runit 20181228-3 0.03 MiB
world/kexec-tools 2.0.17-1 0.24 MiB
system/opentmpfiles 0.2-2 0.05 MiB
system/runit 2.1.2-14 1.69 MiB
system/runit-rc 20190212-1 0.08 MiB
system/dbus 1.12.12-1 0.01 MiB
system/elogind 241.3-1 3.11 MiB
system/libelogind 241.3-1 0.66 MiB
system/libeudev 3.2.7-4 0.18 MiB
world/rtkit 0.12-1 0.14 MiB
Total Installed Size: 7.42 MiB
Net Upgrade Size: 6.35 MiB
This forceful restriction reminds me of Debian/Systemd where you try to install a few KB of a text editor and it wants to bring in some GB of systemd hydra. This is one isolated example but ever since this "
svc-manager" appeared things have been looking hostile for "init freedom".
Artix is not a modified build around Arch, it is its own unique and independent distribution and those decisions on how things are tangled up should weigh on Artix alone. If you run OpenRC and rtkit is functional then runit is unnecessary and vise versa, so why enforce either the one or the other?
I know there are pacman ways around the obstacles but I also think there are better ways to deal with things other than the tendency to provide an alternative init system (or two or three) for arch.
PS Kexec is now mandatory while gksu vanished
One could create some "svc-manager-dummy" package for such a case. I don't think this should be a problem for someone who uses any other init system
svc-manager is not really a package, I don't even know where it is, or what is it called. But packages list it as a dependency. I think it is just a flag somewhere, I don't know where to find it, and I assume it tells various process which init system is installed. It probably tells pacman which branch of Artix it should be on, so it may be all over the place.
I am sad to say, a big fuzz about nothing, you just don't understand how pacman works, and what the provides array in PKGBUILD does.
Answer, eg s6 would just have to implement svc-manager in the PKGBUILD, and you would be able to select a third option, s6.
A none option will never happen, because it would be a nonsensical option.
When runit was first implemented, it worked and I know as I was among the first users here that tried it, this didn't exist, It came later. There is a difference between knowing how pacman works and how you "make a package" which is what you are referring to, I think. Still I don't think this answer real answers the question.
Why -> because -> why would it not be a sensible option? elogind can be installed with openrc, sysvinit, runit, s6, busybox, slew, etc. It is not a different pkg for openrc or runit, it is the same, one of its dependencies mandates that one of the two has to be used. Why? One may even have a subsystem without an init, non-bootable system, that functions through chroot.
PS It is not exactly criticism, it is a genuine question that may help me, possibly others, understand. I am sure there is a technical reason of why it was implemented, it wasn't just added for nothing.
You literally just put this in your PKGBUILD.
provides=('svc-manager')
conflicts=('svc-manager')I actually had no idea this existed but a quick check of pacman -Qi svc-manager suggests that it's likely used for boot related checks to make sure that your box doesn't get screwed if you uninstall openrc packages and switch to runit ones or vice versa.
I frankly have problems to extract a question from your Op besides init providers, which has been answered.
The output you provided says pretty much nothing in regard if this is a basestrap or what is going on?
you are not gonna be able to install packages without also installing svc-manager, which has currently two providers.
Its why a none option makes absolutely no sense, because one of the providers is a dependency.
svc-manager is basically a neutral name for either runit or openrc, so we don't have a specifically named dependency.
Yup that make sense. Having a ton of if/else's around would be silly.
-Qi or -Si only work for a pkg, at least for me it didn't work.
What artoo said about it being a neutral name for either/or makes a bit more sense now.
Thanks to arch's # pacman -Sdd everything is possible as long as one is conscious of what can be messed up.
PS Well, when I first saw it (a while ago) it didn't work ... now it does, This makes no-sense
Required By : alsa-utils-runit artix-sysvcompat cronie-runit device-mapper-runit dhcpcd-runit iptables-runit lvm2-runit mdadm-runit rpcbind-runit