Skip to main content
Recent Posts
1
Package management / Re: Why do runit and openrc packages conflict?
Last post by Dudemanguy -
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."
3
Package management / Re: Why do runit and openrc packages conflict?
Last post by dreieck -
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.
4
Package management / Re: Why do runit and openrc packages conflict?
Last post by dreieck -
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.)
5
Package management / Re: Why do runit and openrc packages conflict?
Last post by artoo -
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.
7
Package management / Re: Why do runit and openrc packages conflict?
Last post by Dudemanguy -
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.
8
Package management / Re: Why do runit and openrc packages conflict?
Last post by E5ten -
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.
9
S6 / Re: We have a pulse!
Last post by fungalnet -
With all the talk about archbang (systemd arch based) in this other thread recently, since I tried it to help out someone liking archbang, I knew that converting to artix is pretty straight forward.  What I got interested in was that there was no dm, autostart/login, and no consolekit or cgmanager.  I thought this wouldn't work with s6.
Autostart x doesn't work, but after login xinit opens up the desktop and everything works.  I'm still trying to solve the puzzle.
In previous experiments trying to get rid of ck I couldn't get xserver running, unless I employed some dm.
One important detail in making s6 work right is to run pacopts origin after installation, as there are pkgs from arch (and artix) that may have the same version as obarun but are different.  Pacopts goes through the list of the obarun repository and what is installed and asks to replace some with obarun's version.

Meanwhile obarun is ready-ing a whole new array of stage2 tools called 66 to replace s6opts.