[pacman-dev] Alternatives system brainstorm

[Andrew Gregory]

On 10/19/19 at 10:43pm, Allan McRae wrote:
> On 19/10/19 10:41 pm, Allan McRae wrote:
> > On 19/10/19 10:38 pm, Allan McRae wrote:
> >> On 19/10/19 10:24 pm, Andrew Gregory wrote:
> >>> No rebuilding necessary if the conflicts are changed to just 'sh'.
> >>
> >> What will happen with "pacman -S dash"?  My initial thought is dash will
> >> pull in the first provider of sh - sh-bash - which will then pull in bash.
> > 
> > I forgot - pacman queries the user when multiple providers.
> 
> $ pacman -S b
> resolving dependencies...
> :: There are 2 providers available for foo:
> :: Repository test
>    1) a-foo  2) b-foo
> 
> Enter a number (default=1):
> 
> It just picks the wrong one by default...

Implementing something like https://bugs.archlinux.org/task/62480
would take care of that.

In order for an alternatives system to be worth it, I think it needs
to be able to provide better flexibility than these link packages.
For example, you mentioned using it for something like python.
Imagine python4 ships IDLE separately; in order to use link packages
you'd need something like python4-links-interpreter and
python4-links-idle, and you'd probably want an all-encompassing
python4-links for convenience too.  That would get unwieldy pretty
quickly.  An alternatives system could allow the user to use python4
for everything else but leave idle pointing to an older version until
idle4 is installed.

So the features I think would be useful are:
1) the ability to select alternatives per-file
2) the ability to select alternatives per-package
3) the ability to group alternatives, potentially spanning multiple
   packages, and select them per-group

As for conflicts, I think go with first-installed-wins and print
a warning when a package gets a new alternative entry and the link is
already set to something else.