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.