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

Why do runit and openrc packages conflict?

The runit init system and openrc init system as well as their initscript packages all conflict, but from what I can see there are no file conflicts. I would like to try runit on my already openrc system, is there any reason this barrier is in place?

Re: Why do runit and openrc packages conflict?

Reply #1 –
Quote from: E5ten – on
The runit init system and openrc init system as well as their initscript packages all conflict, but from what I can see there are no file conflicts. I would like to try runit on my already openrc system, is there any reason this barrier is in place?
Only openrc and runit conflict directly. Their respective initscripts conflict indirectly via their immediate dependencies on openrc or runit. You can easily uninstall openrc with pacman -Rdd and install runit with its needed initscripts, but keep a bootable media at hand.

Re: Why do runit and openrc packages conflict?

Reply #2 –
Multiple initscript packages also conflict, for example look at elogind-openrc and elogind-runit, both conflicting with and providing init-elogind.

Re: Why do runit and openrc packages conflict?

Reply #3 –
Why wouldn't they conflict?  It is either you have runit or OpenRC for an init system, why would you need the scripts for the other?
By removing the one and installing the other this conflict of scripts helps you identify which services you had on one that you should have on the other.  If you use pacman -Si on any pkg it tells you what its dependencies and conflicts are.

Code: [Select]
# pacman -Si dbus-runit
# pacman -Si elogind-runit

Follow the wiki and even if you mess something up it can be fixed by chrooting from another installation or live medium.

Re: Why do runit and openrc packages conflict?

Reply #4 –
Because my goal is to try runit, not remove my entire openrc installation, in addition I think the 2 init systems themselves shouldn't conflict, and initswitch should choose the most recently installed one and also be a command that the user can run to recreate symlinks to the init they want to select, that way you can have both init systems installed and easily switch between the two for testing and experimentation.
EDIT: in addition, even if you can't see a use case for having initscripts for both installed while only having one init installed, there is still no reason to make packages with no conflicting files conflict.

Re: Why do runit and openrc packages conflict?

Reply #5 –
My own opinion is what you are asking for is adding complication for little benefit.

Especially if you have a separate root partition it's easy to make a backup image of the root partition and then play around with the other init and if you don't like it revert to the backup.

Or clone your root partition, set up grub so you boot into either of them and you can install runit on one and openrc on the other.

I can't see many people wanting to switch back and forth on a regular basis but have been wrong before :)

Re: Why do runit and openrc packages conflict?

Reply #6 –
I don't see how removing a conflicts section from initscript PKGBUILDs that don't actually conflict is added complexity, if you mean the bit about initswitch that's just an idea and doesn't matter too much.

Re: Why do runit and openrc packages conflict?

Reply #7 –
Quote from: E5ten – on
I think the 2 init systems themselves shouldn't conflict

They absolutely should, you also don't have a street car with two steering wheels.
It is the same as with other things, you got to make a conscious choice.
The only situation openrc and runit would be installed together was if runit functioned as supervisor for openrc.
But, openrc has its own supervisor.

Re: Why do runit and openrc packages conflict?

Reply #8 –
The only reason packages need to conflict are when the files conflict. I see no reason to artificially make it so only one init system can be installed at a time.

Re: Why do runit and openrc packages conflict?

Reply #9 –
The only use those scripts have is by the init system itself.  If you open and read what a script for either one looks like I doubt you would find a reason for keeping it installed for no reason.  If you don't erase your cache they will still be there and it takes a couple of minutes to install all of them.
So theoretically you may have a point, practically it makes no sense to keep useless packages installed.

Re: Why do runit and openrc packages conflict?

Reply #10 –
Quote from: E5ten – on
Multiple initscript packages also conflict, for example look at elogind-openrc and elogind-runit, both conflicting with and providing init-elogind.
And that's why they conflict, for providing the same package. If you want you can force your way into things (pacman -Sdd), but you won't get any support. Note that -Sdd won't work on conflicting files, only on deps.

Re: Why do runit and openrc packages conflict?

Reply #11 –
Quote from: nous – on
And that's why they conflict, for providing the same package. If you want you can force your way into things (pacman -Sdd), but you won't get any support. Note that -Sdd won't work on conflicting files, only on deps.
They do not have any conflicting files though, which is why there is no reason to make the packages conflict.

Re: Why do runit and openrc packages conflict?

Reply #12 –
These two files I believe is all there is in dbus-runit (including the directory hierarchy they create if it doesn't exist already).

Code: [Select]
% cat /etc/runit/sv/dbus/run
#!/bin/sh
dbus-uuidgen --ensure=/etc/machine-id
[ ! -d /run/dbus ] && install -m755 -g 81 -o 81 -d /run/dbus
exec dbus-daemon --system --nofork --nopidfile

% cat /etc/runit/sv/dbus/check
#!/bin/sh
exec dbus-send --system / org.desktop.DBus.Peer.Ping >/dev/null 2>&1

But this whole /etc/runit maze would be standing there useless, if you are running openrc, like a flower pot on your window without a plant in it.  The dbus-openrc is similar if you were running runit.

If you can point me towards another distro that has two effective init systems available, to see how they have handled this matter, it would be educational.  Imagine the alternative, where the init system was packaged with all available scripts in it, and you had all of them installed despite of whether you had any use for them or not.  You would just install runit or openrc, and then a gui (like systemd) to enable and disable services.  There would be nothing to complain about then.  It is either all or nothing.

I still fail to see your point, and I think others who have responded fail to see it too.

Re: Why do runit and openrc packages conflict?

Reply #13 –
Because - it is like it is.
Because - you want to.
Fine! Pacman can help you:
Code: [Select]
$ pacman -R --help
$ sudo pacman -R --dbonly <pkgname>
;D

Re: Why do runit and openrc packages conflict?

Reply #14 –
Perhaps '-dd' as previously suggested might be better as it would probably work better with updates. I do see a point to this though, firstly you would expect to be able to install more than one browser, desktop, text editor, theme, kernel and so on, and not have to uninstall and reinstall them every time you felt like a change. And if you were developing and testing something and wanted to try it out now and again, and have easy access to study the file structure, file contents and documentation of different inits, it would be genuinely useful to have the latest version of each installed and automatically updated. It would make a simple backup too, if you could chroot in and swap inits with a single command. Then you could mess about with one init and easily recover if you broke it. But then you can probably still do all this as things are now with a few more commands.