Artix Linux => Package management => Topic started by: E5ten on 25 October 2018, 23:54:43
Title: Why do runit and openrc packages conflict?
Post by: E5ten on 25 October 2018, 23:54:43
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?
Title: Re: Why do runit and openrc packages conflict?
Post by: nous on 26 October 2018, 02:18:40
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.
Title: Re: Why do runit and openrc packages conflict?
Post by: E5ten on 26 October 2018, 14:35:03
Multiple initscript packages also conflict, for example look at elogind-openrc and elogind-runit, both conflicting with and providing init-elogind.
Title: Re: Why do runit and openrc packages conflict?
Post by: fungalnet on 26 October 2018, 15:00:37
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.
Follow the wiki (https://wiki.artixlinux.org/Main/Runit) and even if you mess something up it can be fixed by chrooting from another installation or live medium.
Title: Re: Why do runit and openrc packages conflict?
Post by: E5ten on 26 October 2018, 17:21:28
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.
Title: Re: Why do runit and openrc packages conflict?
Post by: gripped on 26 October 2018, 18:47:55
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 :)
Title: Re: Why do runit and openrc packages conflict?
Post by: E5ten on 26 October 2018, 19:23:13
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.
Title: Re: Why do runit and openrc packages conflict?
Post by: artoo on 26 October 2018, 21:47:28
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.
Title: Re: Why do runit and openrc packages conflict?
Post by: E5ten on 26 October 2018, 21:57:03
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.
Title: Re: Why do runit and openrc packages conflict?
Post by: fungalnet on 27 October 2018, 00:10:39
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.
Title: Re: Why do runit and openrc packages conflict?
Post by: nous on 27 October 2018, 02:19:53
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.
Title: Re: Why do runit and openrc packages conflict?
Post by: E5ten on 27 October 2018, 03:49:20
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.
Title: Re: Why do runit and openrc packages conflict?
Post by: fungalnet on 27 October 2018, 10:07:08
These two files I believe is all there is in dbus-runit (including the directory hierarchy they create if it doesn't exist already).
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.
Title: Re: Why do runit and openrc packages conflict?
Post by: ####### on 27 October 2018, 19:16:19
Because - it is like it is. Because - you want to. Fine! Pacman can help you:
Title: Re: Why do runit and openrc packages conflict?
Post by: ####### on 28 October 2018, 02:22:57
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.
Title: Re: Why do runit and openrc packages conflict?
Post by: artoo on 01 November 2018, 16:25:15
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.
You are a bit comparing different things, a browser and applications are not in the same category as a system software such as the init system. Compare the init system with a motor of a car, you would probably not decide tomorrow to swap out the motor of your car, and two days later back to the old motor again. To test eg init related stuff, you simply have two vbox installs with each init system. To avoid any confusion on the user's end, we simply do not allow two init systems installed in parallel, as any other distro also does, for good reasons. In simple terms, there is a choice to make which init system you want to use.
Title: Re: Why do runit and openrc packages conflict?
Post by: ####### on 03 November 2018, 16:28:19
Some distros actually insist that one init remains on the system when another is installed - surely that idea will never catch on. Personally I've been quite happy using just OpenRC, I think the default shutdown sequence is more considerate than most, but if I felt like trying something else then it's useful to know that there are no conflicting files.
Title: Re: Why do runit and openrc packages conflict?
Post by: fungalnet on 03 November 2018, 23:23:35
Are you sure you are not confusing init system with service supervisors? Runit for example. as a service supervisor, exists even in Debian repositories and could work on top of systemd. Probably fedora and rehl. OpenRC was used on top of sysv with the same role. But two init systems together active can only be trouble, I think.
Title: Re: Why do runit and openrc packages conflict?
Post by: konimex on 04 November 2018, 08:35:41
I think before we continue this discussion we need to agree on what is an init and what is an init system since I think there's a confusion.
For instance, is suckless init (https://core.suckless.org/sinit/) a complete init system?
Title: Re: Why do runit and openrc packages conflict?
Post by: phoenix_king_rus on 04 November 2018, 09:17:08
For instance, is suckless init (https://core.suckless.org/sinit/) a complete init system?
>suckless >complete system I would say no suckless program is a system, it is only a program serving some purpose. Sinit provides only init, all other is on users side. It doesn't even provide shutdown/reboot commands itself. I don't even speak about service supervisor (but there is svc (https://core.suckless.org/svc/) as an example). P.S. I really use sinit as my main init on both my Artix systems. For me it works as fast runit does
Title: Re: Why do runit and openrc packages conflict?
Post by: konimex on 05 November 2018, 14:52:12
>suckless >complete system I would say no suckless program is a system, it is only a program serving some purpose. Sinit provides only init, all other is on users side. It doesn't even provide shutdown/reboot commands itself. I don't even speak about service supervisor (but there is svc (https://core.suckless.org/svc/) as an example). P.S. I really use sinit as my main init on both my Artix systems. For me it works as fast runit does
I'm only asking if sinit is a complete "init system" because of ####### (https://forum.artixlinux.org/index.php/topic,724.msg5649.html#msg5649)'s statement earlier "Some distros actually insist that one init remains on the system when another is installed" (I actually don't know what "init" refers to, PID1 or "init system"). Yes, it is impossible to run two simultaneous init (as in PID1), but it is possible to have multiple init systems, though only if you have a very specific/made-up purposes (and it would be redundant (and dangerous), in almost every case).
Anyway, you mentioned that you used sinit as PID1, since it's supposed to be OS-agnostic, it'd make sense to not include any reboot/shutdown command by itself since it's a kernel syscall (it would differ between Linux and... say, OpenBSD).
Since a complete init system mainly consists of init/PID1 and rc (and/or service management system), if you're using sinit, what's your /etc/rc? Hand-made?
Title: Re: Why do runit and openrc packages conflict?
Post by: phoenix_king_rus on 05 November 2018, 15:25:02
Since a complete init system mainly consists of init/PID1 and rc (and/or service management system), if you're using sinit, what's your /etc/rc? Hand-made?
I wrote service launcher inspired by svc to work with sinit. This way rc.init and rc.shutdown become very simple scripts However i also need ubase for some utilities
Title: Re: Why do runit and openrc packages conflict?
Post by: E5ten on 05 November 2018, 15:29:27
I don't think any of these complexities really need to inform the decision, my attitude towards this is simply that packages that do not have conflicting files should not conflict. Any kind of arbitrary limitation over the user whether or not you see a use case feels unnecessary.
Title: Re: Why do runit and openrc packages conflict?
Post by: artoo on 05 November 2018, 18:21:32
I don't think any of these complexities really need to inform the decision, my attitude towards this is simply that packages that do not have conflicting files should not conflict. Any kind of arbitrary limitation over the user whether or not you see a use case feels unnecessary.
That 's fine, but bottom line is, we will not change it, because how we set the init symlink to either openrc-init or runit-init. Other reasons have been stated as well allowing two init systems in parallel spells trouble for users, needless trouble.
Title: Re: Why do runit and openrc packages conflict?
Post by: dreieck on 09 November 2018, 12:56:56
I am a bit *pissed of* by the attitude "i cannot see a use case, so I forbit it".
Well, one core of hacking is to put things together in a way they were not designed for initially. Be it to create functionality, to suit some corner-case use case, for educational purposes, ...
And hacker-friendly systems should not forbit anything artificially because some user-experience designer thinks that for the thought-of use case something else is not needed. As long as something else also does not harm, why to forbit something else?
If someone has 2 init systems in parallel it is his conscious choice. Files just lying around don't harm the system in any way.
And having two different browsers, text editors, kernels or init systems is from my point of view a similar thing, just on a different level. And when your working level is on the base of init system/ system basics, why not having more than one, as someone who works daily with the browser?
Title: Re: Why do runit and openrc packages conflict?
Post by: gripped on 09 November 2018, 13:59:15
I am a bit *pissed of* by the attitude "i cannot see a use case, so I forbit it".
Well, one core of hacking is to put things together in a way they were not designed for initially. Be it to create functionality, to suit some corner-case use case, for educational purposes, ...
And hacker-friendly systems should not forbit anything artificially because some user-experience designer thinks that for the thought-of use case something else is not needed. As long as something else also does not harm, why to forbit something else?
If someone has 2 init systems in parallel it is his conscious choice. Files just lying around don't harm the system in any way.
And having two different browsers, text editors, kernels or init systems is from my point of view a similar thing, just on a different level. And when your working level is on the base of init system/ system basics, why not having more than one, as someone who works daily with the browser?
There is a difference between 'forbidden' and 'unsupported'
If a user really wants two init's installed it would be fairly trivial to edit the PGKBUILD's and a few scripts and symlinks to make it possible for yourself. You could share the instructions on how it's achieved on a forum topic. If that user cannot do it they could pay someone who can to do it or ask other users for help etc.
Nothing is forbidden. Do what you want with your box. But you can't expect distro's to support every use case.
Title: Re: Why do runit and openrc packages conflict?
Post by: artoo on 09 November 2018, 15:58:35
I am a bit *pissed of* by the attitude "i cannot see a use case, so I forbit it".
It's not forbidden, it's made to conflict and that's a huge difference. You can install all the scripts you want, only you'll have to use the right pacman options. OpenRC and runit themselves are an exception, for reasons explained thoroughly. I suggest you edit the PKGBUILD of either of them and hack it the way you want.
Title: Re: Why do runit and openrc packages conflict?
Post by: dreieck on 09 November 2018, 16:56:18
I await your solution to what default init grub is supposed to start.
Grub starts Linux.
Linux starts the first process, by default /sbin/init, but can be configured with kernel command line parameters (init=<path-to-executable>).
Choosing the init system can be done e.g. by having /sbin/init be a symlink pointing somewhere or by specifying parameters to Linux, can be done in the bootloader configuration.
Grub does not start any init.
Title: Re: Why do runit and openrc packages conflict?
Post by: Dudemanguy on 09 November 2018, 17:37:07
Seems like you're splitting hairs over semantics here. Grub (or any other bootloader) tells Linux what init to start.
Title: Re: Why do runit and openrc packages conflict?
Post by: artoo on 09 November 2018, 19:06:28
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.
Title: Re: Why do runit and openrc packages conflict?
Post by: nous on 10 November 2018, 14:29:40
@dreieck Technically, one could use 2 entries in grub.cfg:
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 (https://forum.artixlinux.org/index.php/board,7.0.html) and let other users benefit. I'd like to test it too, cause I'm too lazy to switch inits as it is.
Title: Re: Why do runit and openrc packages conflict?
Post by: fungalnet on 10 November 2018, 16:41:07
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 (https://adelielinux.org/), 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.
Title: Re: Why do runit and openrc packages conflict?
Post by: konimex on 11 November 2018, 02:00:08
There is a young project called Adélie linux (https://adelielinux.org/), 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.
Title: Re: Why do runit and openrc packages conflict?
Post by: E5ten on 13 November 2018, 02:37:38
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.
Title: Re: Why do runit and openrc packages conflict?
Post by: Dudemanguy on 13 November 2018, 15:19:00
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.
Title: Re: Why do runit and openrc packages conflict?
Post by: dreieck on 13 November 2018, 16:19:18
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.
Title: Re: Why do runit and openrc packages conflict?
Post by: dreieck on 13 November 2018, 16:22:00
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.)
Title: Re: Why do runit and openrc packages conflict?
Post by: dreieck on 13 November 2018, 16:35:28
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.
Title: Re: Why do runit and openrc packages conflict?
Post by: artoo on 13 November 2018, 17:01:22
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."
Title: Re: Why do runit and openrc packages conflict?
Post by: nous on 14 November 2018, 02:05:20
% 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 ...
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.
Title: Re: Why do runit and openrc packages conflict?
Post by: fungalnet on 14 November 2018, 11:41:22
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.
Title: Re: Why do runit and openrc packages conflict?
Post by: artoo on 14 November 2018, 12:46:39
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.
Title: Re: Why do runit and openrc packages conflict?
Post by: ####### on 14 November 2018, 16:48:06
I searched to see if pacman has an alternatives / update-alternatives equivalent, but it seems it doesn't, and the Arch philosophy is to use the latest version of everything, not have different possibilities. /usr/bin/init isn't a symlink, it's a binary that checks if runit or openrc is installed: $ pacman -Qo /usr/bin/init /usr/bin/init is owned by artix-sysvcompat 0.3.7-9 And it doesn't only deal with init, if you look at the source, it has to remap the shutdown / reboot commands too, so installing 2 inits wouldn't be quite as simple as just dealing with /usr/bin/init.
Title: Re: Why do runit and openrc packages conflict?
Post by: artoo on 14 November 2018, 18:18:58
/usr/bin/init isn't a symlink, it's a binary that checks if runit or openrc is installed:
No its not, it is a symlink, I implemented it, it is set depending what you install.
Title: Re: Why do runit and openrc packages conflict?
Post by: ####### on 15 November 2018, 16:17:11
Oh yes, you are right of course, I did this: $ pacman -Qo /usr/bin/init /usr/bin/init is owned by artix-sysvcompat 0.3.7-9 and looked at in a text editor (but that followed the symlink, of course) But I should also have done this! $ ls -l /usr/bin/init lrwxrwxrwx 1 root root 11 Oct 24 21:42 /usr/bin/init -> openrc-init ;D Lucky someone knows how it works then :)
Title: Re: Why do runit and openrc packages conflict?
Post by: E5ten on 15 November 2018, 18:02:40
But whether or not the 2 inits conflict, which is reasonable, there is no reason for the initscripts to conflict except through their dependencies on the conflicting inits.
Title: Re: Why do runit and openrc packages conflict?
Post by: artoo on 15 November 2018, 19:23:07
But whether or not the 2 inits conflict, which is reasonable, there is no reason for the initscripts to conflict except through their dependencies on the conflicting inits.
You really should look a bit deeper how pacman groups and the provides array work.