Pacman: There are N providers available for X
Hi, I'm installing a new system, and using the instructions at https://wiki.archlinux.org/title/Pacman/Tips_and_tricks sections 2.5 and 2.6 to get the list of packages to install from my current system. When I run the `pacman -S --needed - < pkglist.txt` part, I get a few cases where pacman says "There are N providers available for X`. What I did for those cases is look up the providers in the `Package Search` page on the archlinux.org and chose the most recent one. Is that a reasonable strategy to use? Is there a better way to make the decision? Searching the web for that string didn't really provide any useful answers unfortunately. Regards Spencer
On 2023-03-26 07:55:06 (+0100), Spencer Collyer wrote:
I'm installing a new system, and using the instructions at https://wiki.archlinux.org/title/Pacman/Tips_and_tricks sections 2.5 and 2.6 to get the list of packages to install from my current system.
When I run the `pacman -S --needed - < pkglist.txt` part, I get a few cases where pacman says "There are N providers available for X`.
There are multiple situations where one thing is provided by several packages. This is also referred to as a "virtual provides", as the thing that the packages provide usually do not exist as a package themselves. Good examples are: * jack2 and pipewire-jack both providing jack (more specifically both provide libjack.so), which is required by a multitude of pro-audio packages * qemu-virtiofsd and virtiofsd both providing virtiofsd-provider (required by QEMU)
What I did for those cases is look up the providers in the `Package Search` page on the archlinux.org and chose the most recent one. Is that a reasonable strategy to use?
Is there a better way to make the decision?
The answer to that is "it depends". Depending on what you want to do and how you want to run your system, you can choose one or the other. To stick with above examples: * use jack2 if you want to use jack2 and pulseaudio. use pipewire-jack if you want to run all your audio via pipewire and have it also provide JACK. * use qemu-virtiofsd if you want to stick with what upstream QEMU provides until it is deprecated (soon). Use virtiofsd if you want to rely on something written in Rust and live in the future now already. Generally, you will likely want to investigate a bit before installing as not all providers of a thing are the same of course :) I hope this cleared up some of the confusion. Best, David -- https://sleepmap.de
Am 26.03.23 um 09:25 schrieb David Runge:
On 2023-03-26 07:55:06 (+0100), Spencer Collyer wrote:
I'm installing a new system, and using the instructions at https://wiki.archlinux.org/title/Pacman/Tips_and_tricks sections 2.5 and 2.6 to get the list of packages to install from my current system.
When I run the `pacman -S --needed - < pkglist.txt` part, I get a few cases where pacman says "There are N providers available for X`.
There are multiple situations where one thing is provided by several packages. This is also referred to as a "virtual provides", as the thing that the packages provide usually do not exist as a package themselves.
But why are these meta packages part of the generated list? I would expect only real packages there. Or have you Spencer Collyer used some combined command to get the list of installed packages? Regards, Uwe
On 27/3/23 15:30, Uwe Koloska wrote:
Am 26.03.23 um 09:25 schrieb David Runge:
On 2023-03-26 07:55:06 (+0100), Spencer Collyer wrote:
I'm installing a new system, and using the instructions at https://wiki.archlinux.org/title/Pacman/Tips_and_tricks sections 2.5 and 2.6 to get the list of packages to install from my current system.
When I run the `pacman -S --needed - < pkglist.txt` part, I get a few cases where pacman says "There are N providers available for X`.
There are multiple situations where one thing is provided by several packages. This is also referred to as a "virtual provides", as the thing that the packages provide usually do not exist as a package themselves.
But why are these meta packages part of the generated list? I would expect only real packages there.
I guess it is because say you have a virtual package named "emoji-fonts" that is provided by real packages "noto-emoji" and "joypixels-font". What other real packages will do is to depend on "emoji-fonts" (not "noto-emoji" or "joypixels-font") so that you (the user) can choose which want to use to fulfill the dependency. Now, imagine that "gnome" depends on "emoji-fonts". When pacman computes the dependency graph it only finds you need "emoji-fonts", not the real packages. So then, it searches who implement "emoji-fonts" and asks you to choose. But you are in fact installing the virtual and the real package, meaning that pacman database will probably contain both. Does that make sense?
On Mon, 27 Mar 2023 15:30:04 +0200, Uwe Koloska wrote:
Am 26.03.23 um 09:25 schrieb David Runge:
On 2023-03-26 07:55:06 (+0100), Spencer Collyer wrote:
I'm installing a new system, and using the instructions at https://wiki.archlinux.org/title/Pacman/Tips_and_tricks sections 2.5 and 2.6 to get the list of packages to install from my current system.
When I run the `pacman -S --needed - < pkglist.txt` part, I get a few cases where pacman says "There are N providers available for X`.
There are multiple situations where one thing is provided by several packages. This is also referred to as a "virtual provides", as the thing that the packages provide usually do not exist as a package themselves.
But why are these meta packages part of the generated list? I would expect only real packages there.
Or have you Spencer Collyer used some combined command to get the list of installed packages?
Regards, Uwe
Hi Uwe, As quoted above, I used the commands given in the Pacman Tips&Tricks page on the Wiki. Specifically I used `pacman -Qqe > pkglist.txt` on my old machine to generate the list of installed packages and then used `pacman -Qqe > pkglist.txt` to install on my new machine. Regards, Spencer
On 28-03-2023 09:22, Spencer Collyer wrote:
On Mon, 27 Mar 2023 15:30:04 +0200, Uwe Koloska wrote:
Am 26.03.23 um 09:25 schrieb David Runge:
I'm installing a new system, and using the instructions at https://wiki.archlinux.org/title/Pacman/Tips_and_tricks sections 2.5 and 2.6 to get the list of packages to install from my current system.
When I run the `pacman -S --needed - < pkglist.txt` part, I get a few cases where pacman says "There are N providers available for X`. There are multiple situations where one thing is provided by several
On 2023-03-26 07:55:06 (+0100), Spencer Collyer wrote: packages. This is also referred to as a "virtual provides", as the thing that the packages provide usually do not exist as a package themselves. But why are these meta packages part of the generated list? I would expect only real packages there.
Or have you Spencer Collyer used some combined command to get the list of installed packages?
Regards, Uwe Hi Uwe,
As quoted above, I used the commands given in the Pacman Tips&Tricks page on the Wiki. Specifically I used `pacman -Qqe > pkglist.txt` on my old machine to generate the list of installed packages and then used `pacman -Qqe > pkglist.txt` to install on my new machine.
Regards,
Spencer
The "N providers available for X" message doesn't relate to the packages on the generated list , but to the dependencies of one or more of those packages on the list . Incase you don't want those questions, check which package you prefer to provide that dependency, change it's install reason to explicit and regenerate the list. LW
Hi LW,
Incase you don't want those questions, check which package you prefer to provide that dependency, change it's install reason to explicit and regenerate the list.
That seems like a bit of a bodge though. If I wanted to duplicate the packages from one machine to another then I'd like the method to not alter the source machine, preserve my choices, and that some packages weren't explicitly wanted. In other words, duplicate. Perhaps the wiki's method didn't keep up with changes to the package meta-data which creates the issue. And that might be because pacman(1) doesn't help in the needed way. -- Cheers, Ralph.
On 28-03-2023 11:41, Ralph Corderoy wrote:
Hi LW,
Incase you don't want those questions, check which package you prefer to provide that dependency, change it's install reason to explicit and regenerate the list. That seems like a bit of a bodge though. If I wanted to duplicate the packages from one machine to another then I'd like the method to not alter the source machine, preserve my choices, and that some packages weren't explicitly wanted. In other words, duplicate.
Perhaps the wiki's method didn't keep up with changes to the package meta-data which creates the issue. And that might be because pacman(1) doesn't help in the needed way.
The -e flag does what the manpage says it does : show all explicitly installed packages Whether packages are meta , split , virtual, have 0 deps or 500 deps (to name a few possiblities) has no effect on the installreason . It seems that is not what you want, could you explain what you do want to achieve ? LW
Hi LW,
If I wanted to duplicate the packages from one machine to another then I'd like the method to not alter the source machine, preserve my choices, and that some packages weren't explicitly wanted. In other words, duplicate. ... ...could you explain what you do want to achieve ?
Well, I'm not the original OP but I have wondered about how to do this in the past. ‘pacman -Qqe’ lists the packages I've explicitly installed; call that set E. If the dependencies of those refer to a virtual package and I satisfied it in the past on machine A by choosing package P then I don't think that adds P to the explicitly installed set. On machine B, I want to explicitly install package set E and have the choice of P made automatically. I don't want to make P explicitly installed on either machine A or B because it is just a dependency. At every pick-a-package question on B, I could look on A to see how to re-make the same choice as before but that assumes A is available and is a tedious manual procedure. Hope that's clearer. Perhaps I've a faulty assumption early on which makes my problem disappear. -- Cheers, Ralph.
On 28-03-2023 14:42, Ralph Corderoy wrote:
Hi LW,
If I wanted to duplicate the packages from one machine to another then I'd like the method to not alter the source machine, preserve my choices, and that some packages weren't explicitly wanted. In other words, duplicate. ... ...could you explain what you do want to achieve ? Well, I'm not the original OP but I have wondered about how to do this in the past.
‘pacman -Qqe’ lists the packages I've explicitly installed; call that set E.
If the dependencies of those refer to a virtual package and I satisfied it in the past on machine A by choosing package P then I don't think that adds P to the explicitly installed set. correct On machine B, I want to explicitly install package set E and have the choice of P made automatically. I don't want to make P explicitly installed on either machine A or B because it is just a dependency.
At every pick-a-package question on B, I could look on A to see how to re-make the same choice as before but that assumes A is available and is a tedious manual procedure.
Hope that's clearer. Perhaps I've a faulty assumption early on which makes my problem disappear.
Yup, much clearer. Pacman only has one mechanism to automate choices : --noconfirm . It is intended for scripts to answer pacman y/n questions and execute the default option. I am not 100% sure but do think it also does the same for N providers avaiiable for X questions and chooses the first (alphabetically) one in the providers list. Whether that is a good choice is another question . vulkan-driver is an example were the first choice is amdvlk and choosing this will often give problems with vulkan later. (just search the forum, plenty of people that choose that without considering if it was the correct choice) The correct answer to those N / X questions depends on factors unknown to pacman and is very hard to automate . A possible workaround could be to identify the virtual provides and choose a sensible provider for them. Those sensible choices would be entered in a set F that will be installed with --asdeps BEFORE set E. for vulkan-driver the sensible provider could be vulkan-swrast which uses the porcessor to implement vulkan support in software and should work on every system running archlinux. LW
Hi LW,
A possible workaround could be to identify the virtual provides and choose a sensible provider for them.
Those sensible choices would be entered in a set F that will be installed with --asdeps BEFORE set E.
Ah, that's given me an idea. On machine A, I could ‘pacman -Qqd’ to get set D: all packages installed as dependencies. This will include those I've carefully picked to satisfy a virtual package. On machine B, I install set D with ‘--asdeps --needed’ before installing explicitly-installed set E. On this second run, pacman will find the virtual package's dependencies are already met and no questions will arise. Will that work? Is it a more complete answer for the wiki? -- Cheers, Ralph.
Hi, On Tue, 28 Mar 2023, Lone_Wolf wrote:
On 28-03-2023 14:42, Ralph Corderoy wrote:
Hi LW,
If I wanted to duplicate the packages from one machine to another then I'd like the method to not alter the source machine, preserve my choices, and that some packages weren't explicitly wanted. In other words, duplicate. ... ...could you explain what you do want to achieve ? Well, I'm not the original OP but I have wondered about how to do this in the past.
‘pacman -Qqe’ lists the packages I've explicitly installed; call that set E.
If the dependencies of those refer to a virtual package and I satisfied it in the past on machine A by choosing package P then I don't think that adds P to the explicitly installed set. correct On machine B, I want to explicitly install package set E and have the choice of P made automatically. I don't want to make P explicitly installed on either machine A or B because it is just a dependency.
At every pick-a-package question on B, I could look on A to see how to re-make the same choice as before but that assumes A is available and is a tedious manual procedure.
Hope that's clearer. Perhaps I've a faulty assumption early on which makes my problem disappear.
Yup, much clearer.
Pacman only has one mechanism to automate choices : --noconfirm .
It is intended for scripts to answer pacman y/n questions and execute the default option.
I am not 100% sure but do think it also does the same for N providers avaiiable for X questions and chooses the first (alphabetically) one in the providers list.
Whether that is a good choice is another question .
vulkan-driver is an example were the first choice is amdvlk and choosing this will often give problems with vulkan later. (just search the forum, plenty of people that choose that without considering if it was the correct choice)
The correct answer to those N / X questions depends on factors unknown to pacman and is very hard to automate .
A possible workaround could be to identify the virtual provides and choose a sensible provider for them.
Those sensible choices would be entered in a set F that will be installed with --asdeps BEFORE set E.
for vulkan-driver the sensible provider could be vulkan-swrast which uses the porcessor to implement vulkan support in software and should work on every system running archlinux.
My solution would be to do a "pacman -S --asdeps" with the list of *all* packages installed as dependencies (output of "pacman -Qqd" - set D), and then a "pacman -S --asexplicit" with just the set E (output of "pacman -Qqe"). Note, that if a package was installed as a dependency of some package from set D, but is itself not in D but rather in E, it will be reinstalled in the second step (no big issue, but pacman hooks might trigger again).
LW
regards, Erich
Ralph and Eric had the same idea, creating a list of packages installed as dependencies and use that for the new system. While that will probably work I feel it's error-prone and to much work. Maybe this is an X-Y problem. Why is having to answer the N-providers-for-X questions a problem ? LW
Hi LW,
While that will probably work I feel it's error-prone and to much work.
Maybe this is an X-Y problem. Why is having to answer the N-providers-for-X questions a problem ?
I explained the X of X-Y earlier and thought it was accepted as clear. - How to reproduce the packages installed on machine A on machine B. - Assume both are similar hardware so that's not an issue. - Do not alter machine A. It may not even still be available. - Preserve whether a package was explicitly installed or installed as a dependency. - Automatically resolve the virtual package 1-of-N choices. In other words, bundle up some data on A, move it to B, and ‘Voilà!’.
Ralph and Eric had the same idea, creating a list of packages installed as dependencies and use that for the new system.
I think installing D, the set of A's packages installed as dependencies,
may want some of E's, the explicitly installed ones. So I'm now
thinking:
a$ pacman -Qq >a.all
a$ pacman -Qqe >a.explicit
b$ pacman -S --asdeps --needed
Am 29.03.23 um 12:13 schrieb Ralph Corderoy:
a$ pacman -Qq >a.all a$ pacman -Qqe >a.explicit
b$ pacman -S --asdeps --needed
Make that last line $ pacman -D --asexplicit < a.explicit BR
participants (8)
-
David Runge
-
Erich Eckner
-
Iván Zaera Avellón
-
Lone_Wolf
-
Markus Schaaf
-
Ralph Corderoy
-
Spencer Collyer
-
Uwe Koloska