Skip to main content ↑ ↓
Topic: Why do runit and openrc packages conflict? (Read 9864 times) previous topic - next topic
0 Members and 4 Guests are viewing this topic.

Re: Why do runit and openrc packages conflict?

Reply #30 –
Quote from: Dudemanguy – on
Seems like you're splitting hairs over semantics here. Grub (or any other bootloader) tells Linux what init to start.


Not only that, but the understanding how artix does /usr/bin/init, a symlink, seems limited.
So how does grub know if it should start /usr/bin/openrc-init or /usr/bin/runit-init, would be the question any implementation had to solve if it was to allow these two files in parallel.

Re: Why do runit and openrc packages conflict?

Reply #31 –
@dreieck
Technically, one could use 2 entries in grub.cfg:
Code: [Select]
menuentry 'Artix Linux OpenRC' {
...
  linux /boot/vmlinuz-linux root=/dev/disk/by-label/ROOT init=/usr/bin/openrc-init
  initrd /boot/initramfs-linux.img
}
and
Code: [Select]
menuentry 'Artix Linux runit' {
...
  linux /boot/vmlinuz-linux root=/dev/disk/by-label/ROOT init=/usr/bin/runit-init
  initrd /boot/initramfs-linux.img
}

Then, one should decide how one wants to tell one's chosen init to avoid stepping on the toes of one's other init.

However, because our init systems are true init systems (and not some crap like you-know-whatd - obligatorily inflammatory stub) and the linux kernel by default boots /sbin/init and we fancy adhering to that standard and we must cover the needs of the overwhelming majority of users and we have to make it relatively easy for them to install another init if need be and we're still very low on manpower, we've decided to support only one init at a time.

If you can make a clean working solution, i.e. one that only depends on pacman and not on hackish shell scripts that move files around the filesystem during boot, then please post it to the related subforum and let other users benefit. I'd like to test it too, cause I'm too lazy to switch inits as it is.
 

Re: Why do runit and openrc packages conflict?

Reply #32 –
As I found out, from testing this hypothesis of twin init systems, not all scripts x-runit and x-openrc conflict each other.  Some do, some don't, right?  Even when they do you can force things leaving just a couple of pkgs that you would have to remove and install to switch init systems.  This by far is a very different process than trying to pry systemd out of its place.

There is a young project called Adélie  linux, musl based, open and free, that has sysv, openrc, and s6 readily available in the repositories.  It is still beta and underdocumented, but for people who like exercises in KISS it is very fun.

Re: Why do runit and openrc packages conflict?

Reply #33 –
Quote from: fungalnet – on
There is a young project called Adélie  linux, musl based, open and free, that has sysv, openrc, and s6 readily available in the repositories.  It is still beta and underdocumented, but for people who like exercises in KISS it is very fun.


From a quick glance (looking at their s6 package) their approach is s6 as PID1, OpenRC (specifically sysinit) as rc and s6 again as service manager. I'll try it one day.
now only the dinit guy in artix

Re: Why do runit and openrc packages conflict?

Reply #34 –
But how artix determines /usr/bin/init is still only relevant for keeping the actual 2 init systems conflicting, it still doesn't give a reason to make the initscripts conflict, it isn't like runit initscripts lying around on an openrc system would interfere with anything, and if someone wants to do that for some reason or another there's no real reason they should have to jump through the hoop of editing the PKGBUILD when the files do not conflict in any way, not even through the initswitch thing like the init systems themselves conflict. It's an artificial limitation that doesn't seem to actually provide a benefit. If you don't want to change initswitch to accomodate having both init systems installed that is perfectly understandable, but I see no reason to have 2 packages conflict that have no conflicting files and have no method by which they could harm something by simultaneously being installed.

Re: Why do runit and openrc packages conflict?

Reply #35 –
It's an indirect thing due to how Arch's packaging works. A runit initscript will have a runit dependency while the equivalent openrc initscript will have an openrc dependency. Obviously, runit and openrc conflict, thus the initscripts will conflict with with each other. Now you could say that those dependencies shouldn't be there, but to me that makes absolutely zero sense. Those initscripts are useless without the appropriate init system installed.

Re: Why do runit and openrc packages conflict?

Reply #36 –
Quote from: Dudemanguy – on
Seems like you're splitting hairs over semantics here. Grub (or any other bootloader) tells Linux what init to start.

Or not, since Linux has a default. And there you can also choose by a symlink. A bootloader is just one way to choose the first process.

Re: Why do runit and openrc packages conflict?

Reply #37 –
Quote from: E5ten – on
it still doesn't give a reason to make the initscripts conflict

Quite frankly, we don't own any reason, we just do, and if you don't like it, you can change it to suit your system needs.

I mean, what are we talking about? You found a distro without systemd that offeres two init system alternatives.
Now people come and complain these can't be installed in parallel, which does not make sense and will lead to problems for the average user.

Re: Why do runit and openrc packages conflict?

Reply #38 –
Quote from: Dudemanguy – on
It's an indirect thing due to how Arch's packaging works. A runit initscript will have a runit dependency while the equivalent openrc initscript will have an openrc dependency. Obviously, runit and openrc conflict, thus the initscripts will conflict with with each other. Now you could say that those dependencies shouldn't be there, but to me that makes absolutely zero sense. Those initscripts are useless without the appropriate init system installed.

That's a good point and design choice.

The init scripts conflict indirectly by the init system theiy depend on, but not by themselves. Would be a sane solution.

And then someone who wants to have the initscripts of both init systems installed for whatever reason can create a dummy package which provides the dependency only.

I like that. (And I made such dummy packages for linux and linux-headers already, because some packages depend on that but I use a different way.)

Re: Why do runit and openrc packages conflict?

Reply #39 –
Quote from: artoo – on
Now people come and complain these can't be installed in parallel, which does not make sense and will lead to problems for the average user.

Which problems does the average user get (except of a bit more filled disk space) when he has init scripts installed which are not used? (We are not talking about having two init systems installed, just the init scripts.)

"Doesn't make sense" is not an argument I think to prohibit something. "Does harm" is one, in my opinion.

Re: Why do runit and openrc packages conflict?

Reply #40 –
Quote from: dreieck – on

"Doesn't make sense" is not an argument I think to prohibit something. "Does harm" is one, in my opinion.



I don't have time for this, sorry, if you don't like it, deal with it.

Re: Why do runit and openrc packages conflict?

Reply #41 –
Quote from: dreieck – on
Which problems does the average user get (except of a bit more filled disk space) when he has init scripts installed which are not used? (We are not talking about having two init systems installed, just the init scripts.)

"Doesn't make sense" is not an argument I think to prohibit something. "Does harm" is one, in my opinion.


There's not a practical way for any distro to handle this extreme edge case. As I mentioned before, the reason they conflict is because of conflicting dependencies on openrc and runit. Runit initscripts absolutely need to have runit as a dependency and likewise openrc initscripts absolutely need to have openrc as  a dependency. The point of a package manager is to handle all of the dependency junk for you. It would make no sense to distribute those initscripts without the proper dependencies because they would be completely useless without openrc or runit installed.

Now as you said earlier, one could create "dummy packages" for this that strips out the init dependency to get around the conflict. That's fine, but that's clearly something a user would have to do on his/her own. You can't expect artix to literally duplicate all of their init packages, make a dummy version and put them in the repo. It would be very confusing for anyone doing a search for something like dhcpcd with pacman and seeing odd dummy packages popping up and the benefit would be almost nil.

If you really want to switch init systems on the fly for whatever reason, just write a script for it. It's really not that complicated to do. You just need to find all the packages with -openrc or -runit in their name and replace with them with the opposite. That's the most practical, sane solution to this "problem."

Re: Why do runit and openrc packages conflict?

Reply #42 –
Code: [Select]
% sudo pacman -S runit
resolving dependencies...
looking for conflicting packages...
:: runit and openrc are in conflict (svc-manager). Remove openrc? [y/N] y
:: runit-rc and kmod-openrc are in conflict (init-kmod). Remove kmod-openrc? [y/N] y
:: runit-rc and eudev-openrc are in conflict (init-udev). Remove eudev-openrc? [y/N] y
:: runit-rc and opentmpfiles-openrc are in conflict (init-opentmpfiles). Remove opentmpfiles-openrc? [y/N] y
:: runit-rc and opensysusers-openrc are in conflict (init-opensysusers). Remove opensysusers-openrc? [y/N] y
:: elogind-runit and elogind-openrc are in conflict (init-elogind). Remove elogind-openrc? [y/N] y
:: dbus-runit and dbus-openrc are in conflict (init-dbus). Remove dbus-openrc? [y/N] y
...

% egrep -ir "svc-manager|init-kmod" */trunk/*
artix-sysvcompat/trunk/PKGBUILD:depends=('svc-manager')
kmod-openrc/trunk/PKGBUILD:provides=('init-kmod')
kmod-openrc/trunk/PKGBUILD:conflicts=('init-kmod')
openrc/trunk/PKGBUILD:    provides=('svc-manager')
openrc/trunk/PKGBUILD:    conflicts=('svc-manager')
runit-rc/trunk/PKGBUILD:provides=('init-kmod' 'init-udev' 'init-opentmpfiles' 'init-opensysusers')
runit-rc/trunk/PKGBUILD:conflicts=('init-kmod' 'init-udev' 'init-opentmpfiles' 'init-opensysusers')
runit/trunk/PKGBUILD:provides=('svc-manager')
runit/trunk/PKGBUILD:conflicts=('svc-manager')
If anyone's interested, building openrc and runit takes only a few seconds and they're free to remove the "conflicts" arrays from the PKGBUILDs (and see what happens). The openrc and runit initscripts can be easily installed side-by-side with a simple pacman -Sdd.

The decision to make our init systems conflict was taken unanimously by the developers in #artix-dev, where the technical details were also discussed, and it will stay as it is.

Re: Why do runit and openrc packages conflict?

Reply #43 –
Just like @dudemanguy said, about making a script of the list of openrc and runit scripts, the switch is almost as quick as switching kernels.
I first tried runit when it was still beta, before the first runit iso came out, and at a very unfortunate moment where a bad gremlins runit pkg appeared and then was corrected but my mirror hadn't caught up.  After that switching from openrc to runit and back, and if you keep your cache, it takes 2'.  You switch, reboot, you are fine.  For my use I never went back to openrc, on a couple of other installarions (non gremlins) I made for people unwilling to learn more and do maintenance I kept them bone stock lxqt openrc.  Playing around on vms with other arch based installations I go back and forth between openrc, runit, and s6 (obarun), in a latter of minutes.   You can simple run "pacman -Qq -openrc" and match the output with "-runit" on the mirror.  A script is made.  If you use -dd as @nous said above you can keep all scripts installed.

I think that summarizes everything that has been said here and I don't see any reason to be going back in loops.  Why keep a gas stove side by side with an electric one, when you live in an area where gas is not supplied?  It is your own freedom to do so.  Pacman also allows you with -w to download any and all pkgs from a mirror and keep them in your cache without installation. 

Re: Why do runit and openrc packages conflict?

Reply #44 –
Bottom line, if we were to allow multiple init systems to be installed in parallel, it would screw up lot of packaging and hell to remove or swap init specific packages. The  /usr/bin/init  has to pick a default. No way around taking one as the default, which is openrc due to alphabetical ordering.

You also don't have a car with petrol and diesel motor, you got to pick one.