Skip to main content ↑ ↓
Topic: What if one wanted to write their own init and supervision system on artix  (Read 1919 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

What if one wanted to write their own init and supervision system on artix

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

Code: [Select]
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

Re: What if one wanted to write their own init and supervision system on artix

Reply #1 –
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
ARMtix

Re: What if one wanted to write their own init and supervision system on artix

Reply #2 –
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.

Re: What if one wanted to write their own init and supervision system on artix

Reply #3 –
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.

Re: What if one wanted to write their own init and supervision system on artix

Reply #4 –
Quote
you just don't understand how pacman works, and what the provides array in PKGBUILD does.

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.

Quote
because it would be a nonsensical option

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.

Re: What if one wanted to write their own init and supervision system on artix

Reply #5 –
You literally just put this in your PKGBUILD.
Code: [Select]
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.

Re: What if one wanted to write their own init and supervision system on artix

Reply #6 –
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.

Re: What if one wanted to write their own init and supervision system on artix

Reply #7 –
Quote from: Dudemanguy – on
You literally just put this in your PKGBUILD.
Code: [Select]
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.


svc-manager is basically a neutral name for either runit or openrc, so we don't have a specifically named dependency.

Re: What if one wanted to write their own init and supervision system on artix

Reply #8 –
Quote from: artoo – on
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.

Re: What if one wanted to write their own init and supervision system on artix

Reply #9 –
Quote from: Dudemanguy – on
a quick check of pacman -Qi svc-manager

-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