Hi, I would like to have some feedback on an idea I've had:
Currently, when packages
package-runit (as an example) and
package both exist in the repositories,
package is a dependency of
package-runit.
The idea would be to make it so that, additionally,
package-runit becomes an optional dependency for
package, to signal that it is extending
package's functionality by adding an init-script for runit.
Pros:- You can easily spot for which programs which init scripts are already available.
- You can mark init scripts as "--asdeps" and keep overviews like pacman -Qe concise and human-readable while not having the scripts removed when removing orphaned packages.
- That way removing packages using pacman -Rs clears init scripts as well.
- The configuration is not uncommon either. For instance, since first switching to Artix-runit, I have the package polkit depending on elogind, which in turn optionally depends on polkit.
- ...
Cons:- When support for a new init-system gets added, pacman will spam new optional dependencies.
- ...
So what do you think? Would that cause you problems/inconveniences with your setup and/or workflows?
Thanks in advance for any feedback :)
PS: I'm new to this forum, so I hope this is the right place for this question and no one has asked this before.
While I did search for a while, feel free to correct me and give tipps.
There's 3 init systems so for every package there would be 3 optional dependencies listed. That's not so bad by itself, but every single optional dependency would conflict with one another which is unintuitive and confusing (imo). It does seem like a lot of users get confused at the separation between init scripts and daemons though.
Plus there are init scripts provided for packages which are in Arch repositories only.
So either way there would be users complaining.
The way how it is now keeps things simple.
All user needs to do is search for init script for given package.
But would they? I guess it would make little to no sense to have more than one, but looking at e.g. dhcpcd-runit, it only adds the runit service directory (as I would expect). Similarly for dhcpcd-s6 and dhcpcd-openrc.
On the other hand, the packages are marked as incompatible :/
What exactly is the problem there?
I'll give you the unintuitive thing though. A rather unexperienced user would certainly expect to be able to install all optional dependencies and benefit from them.
Of course one could dream of modifying pacman to only consider programs which do not conflict with already installed ones, in which case we could just mark dhcpcd-runit incompatible to s6 and openrc, but that seems out of scope already :D
Good point. I guess the only solution would be to mirror all those packages, which is simply too much right now.
Maybe in a few decades when Arch and Artix have rejoined and provide a range of init systems together :P
Honestly, there is nothing forbidding you from writing script to do such a thing.
Most of the Artix init packages follow same naming convention <package>-<init>
PS: I say most because I do not use most of them :)
It's the dependencies. *-runit scripts depend on runit, *-s6 on s6, and *-openrc on openrc. The init systems all conflict with each other (for obvious reasons) and thus causes the scripts to have conflicts. In the case of s6, there are some special commands run when a script gets installed/uninstalled that require you to have a working s6/s6-rc setup. So hypothetically even if the init system dependencies were removed, this would still causes problems.
I think a simpler approach would be adding .install file to packages requiring a script to remind user to install this script
this is linux.... artixlinux/archlinux are designed for advanced linux users, not for kindergarden, which don't want to read/study anything (generally speaking).
pacman -Ss should be known to everyone
We definitely won't change the basic package naming convention and their depends.
There are the handy pacman groups available with
pacman -Sg
.
As for optdepends, unfortunately, these are perhaps not the proper way to go, because init packages are mutualy exclusive, they conflict with each other.
For exampe, the apache package could have all 3 apache-$init as optdepends but its basicly of no use, you pick only one.
Ok, I'm marking this solved then, since my original question seems to have a clear answer.
Thanks for the enlightening replies :)
Still a question on the side:
If we already define things like
acpid-runscripts, I don't see the above as an argument against making these optional dependencies.
When trying to install it, pacman asks which one to install.
Maybe this is an option for the future? Idk.
We would need to provide the scripts for all inits though to avoid confusion.
And this of course does not solve the other issues like SGOrava's.
And this might cause confusion when switching inits.
This problem is pretty well covered in our wiki.
On wiki page for each init we have a section "Installation of services" which explains how to install services for it.
https://wiki.artixlinux.org/Main/OpenRC
https://wiki.artixlinux.org/Main/Runit
https://wiki.artixlinux.org/Main/S6
If user is unable to reach the mentioned section on the wiki page of the selected init system, why did such a person even decided to use Artix in the first place?
$ pacman -Qq |while read pkgline; do pacman -Ss "$pkgline-openrc"; done
Oneliner to check for any missing init scripts (swap the -openrc bit for -runit or -s6 as required. It's a bit slow to run but gets there in the end, you could also swap pacman for an AUR helper to search the AUR as well. ;D
On my system I'm "missing" several init scripts, but these are for things I don't want to run as a service and I use in other ways, or they are deps for something else.
Good way how to spend few minutes :D
So you wanna play this game, huh?? :D
Very well then, here's my approach:
$ pacman -Sl | grep "\-runit" | grep "$(for pkg in $(pacman -Qq); do echo ${pkg}-runit; done)" | grep -v "\[installed\]" | awk '{print $2}'
This may no longer count as a oneliner for its length, but it is reasonably fast. pacman -Syy is recommended beforehand.
You can also specify the Artix reposiories with pacman -Sl to speed things up even more.
And yes, I do like grep :)
Yeah, the question is, who is the "we" there? I am not aware you are part of the dev team.
Look at the depends of these script packages, this answers it.
That was probably my fault from 2016-2017, sorry.
In the past, I named runit services
runscripts because of in the event of s6 future inclusion, it can share the scripts as it has the same roots (daemontools), but since s6 depends on execline, I don't see a point to merge the scripts and decided to scrap them.
The runit scripts would mostly work fine for s6/s6-rc actually (aside from the ones that have some runit-specific commands like chpst). I decided to go with using execline for almost everything though since it uses it internally plus there's some other things you need to do for s6/s6-rc (like a separate type file).