Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: [SOLVED] Make package-init an optional dependency for package? (Read 1632 times) previous topic - next topic
0 Members and 5 Guests are viewing this topic.

[SOLVED] Make package-init an optional dependency for package?

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.

Re: Make package-init an optional dependency for package?

Reply #1 –
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.

Re: Make package-init an optional dependency for package?

Reply #2 –
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.

Re: Make package-init an optional dependency for package?

Reply #3 –
Quote
every single optional dependency would conflict with one another which is unintuitive and confusing

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

Quote
Plus there are init scripts provided for packages which are in Arch repositories only.

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

Re: Make package-init an optional dependency for package?

Reply #4 –
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 :)

Re: Make package-init an optional dependency for package?

Reply #5 –
Quote from: logolive – on
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?

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.

Re: Make package-init an optional dependency for package?

Reply #6 –
I think a simpler approach would be adding .install file to packages requiring a script to remind user to install this script
ARMtix

Re: Make package-init an optional dependency for package?

Reply #7 –
Quote from: phoenix_king_rus – on
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

Re: Make package-init an optional dependency for package?

Reply #8 –
Quote from: logolive – on


So what do you think? Would that cause you problems/inconveniences with your setup and/or workflows?




We definitely won't change the basic package naming convention and their depends.

There are the handy pacman groups available with
Code: [Select]
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.

Re: Make package-init an optional dependency for package?

Reply #9 –
Ok, I'm marking this solved then, since my original question seems to have a clear answer.
Thanks for the enlightening replies :)

Quote
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.

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.

Re: Make package-init an optional dependency for package?

Reply #10 –
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?

Re: Make package-init an optional dependency for package?

Reply #11 –
Code: [Select]
$ 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.

Re: Make package-init an optional dependency for package?

Reply #12 –
Quote from: ####### – on
Code: [Select]
$ 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

Re: Make package-init an optional dependency for package?

Reply #13 –
Quote from: ####### – on
Code: [Select]
$ 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.

So you wanna play this game, huh?? :D
Very well then, here's my approach:
Code: [Select]
$ 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 :)

Re: Make package-init an optional dependency for package?

Reply #14 –
Quote from: logolive – on

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.



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.