FS#62480 - allow setting a default provider for a virtual package

Attached to Project: Pacman
Opened by Ike Devolder (BlackEagle) - Friday, 26 April 2019, 14:41 GMT
Task Type Feature Request
Category General
Status Unconfirmed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version 5.1.3
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 1
Private No

Details

When there are multiple packages providing the same virtual package it should be possible to set a 'sane' default

for example having a dependency on a virtual package KODI-BIN by kodi

and having 3 providers for the KODI-BIN virtual package:
- kodi-gbm
- kodi-wayland
- kodi-x11

the 'sane' default would be to install kodi-x11 since that would work for 90% of the people (even if running on wayland)

but now the default is:

```
:: There are 3 providers available for KODI-BIN:
:: Repository blackeagle-pre-community
1) kodi-gbm 2) kodi-wayland 3) kodi-x11

Enter a number (default=1):
```

So if you go the 'next next next' approach you get a provider that will probably not work for 90% of the people.

It would be nice to have a way to set a default provider for this virtual package like kodi-x11

something like

```
depends=('KODI-BIN:kodi-x11')
```

or maybe have a manual way to sort

```
provides=('KODI-BIN:1')
```

The above are just ideas for the packagers configuration in the PKGBUILD, I currently have no clue how to implement this in pacman itself to process
This task depends upon

Comment by Giancarlo Razzolini (grazzolini) - Friday, 26 April 2019, 14:45 GMT
This discussion also came up in the context of the i3 group virtual package.

That group has both i3-gaps and i3-wm as part of the group. But both packages provide i3-wm. Since the ordering here seems to be alphabetical, i3-gaps is the default, instead of i3-wm.

Having the ability to set the default for a provides= probably can fix both cases. I'm not sure we have other cases like this, but I wouldn't be surprised if there were.
Comment by Andrew Gregory (andrewgregory) - Friday, 26 April 2019, 22:28 GMT
This sounds like quite a lot of work just to make life easier for people not paying attention to what pacman tells them.
Comment by Giancarlo Razzolini (grazzolini) - Friday, 26 April 2019, 23:38 GMT
It sure is a lot of work, no doubt. That doesn't mean it's not useful.
Comment by Andrew Gregory (andrewgregory) - Saturday, 27 April 2019, 05:17 GMT
Well, if people want to see this actually implemented, the first step is to find a way to integrate a default provider into the existing dependency string format. It has to be able to co-exist with a version and/or description.
Comment by Eli Schwartz (eschwartz) - Sunday, 28 April 2019, 02:04 GMT
I tend to agree that the interactive-by-default nature of an interactive dialog is all that is "needed". Honestly, in most cases if you have multiple packages with the same provides, any package should be a drop-in equivalent; the fact that x11/wayland package splits invariably produce giant binary packages that are only an implementation of said provides depending on which windowing toolkit you use, seems to be pretty inelegant already. :p

And then it's wrong for anyone who uses wayland, G-d have mercy on their souls.

...

Personally, my ideal solution would be to get rid of wayland. :p

Alternatively, what about this for an alternative system? Have the main provider (kodi-bin) actually be a real package, which should always be prioritized, since it is the preferred default, yes? And then other packages wishing to be a non-default provider of kodi-bin can advertise that they provide/conflict it. The only issue would be that in order to get this non-default provider you'd need to know what you need, since there is no provides selector if the primary target is a real package. But then, "you'd need to know what you need" seems like an insightful description of wayland...
Comment by Eli Schwartz (eschwartz) - Sunday, 28 April 2019, 02:22 GMT
Actually it appears this solution has already been selected for the kodi package...
Comment by Ike Devolder (BlackEagle) - Sunday, 28 April 2019, 10:35 GMT
Yes, now the real package "kodi-bin" is the choosen solution for kodi, but it does not remove the potential need where you want other sorting or have a preferred package for a virtual one
Comment by Andrew Gregory (andrewgregory) - Sunday, 28 April 2019, 19:41 GMT
Why? Please expand upon that need. As I said, this is a big change as it requires changing the string format for dependencies, so I need more than the bare assertion that it would be kind of useful, and Eli's comment mirrors my initial thoughts pretty much verbatim. If one particular provider is going to be correct for 90% of users, why wouldn't simply depending directly on that provider and letting the 10% manually install another one be acceptable? Or, in cases where there isn't such a strong preference for one particular provider, what's the point in specifying a default when multiple options are equally preferable?

Loading...