On 19/10/19 10:38 pm, Allan McRae wrote:
> On 19/10/19 10:24 pm, Andrew Gregory wrote:
>> On 10/19/19 at 10:15pm, Allan McRae wrote:
>>> On 19/10/19 9:57 pm, Daan van Rossum wrote:
>>>> * on Saturday, 2019-10-19 18:15 +1000, Allan McRae <al...@archlinux.org>
>>>> wrote:
>>>>
>>>>> /bin/sh -> bash/dash
>>>>> /usr/bin/awk -> gawk/nawk
>>>>> /usr/bin/cc -> gcc/clang
>>>>
>>>> Can we provide alternatives by means of sets of mutually exclusive link
>>>> packages, using package properties that are already supported in pacman?
>>>>
>>>> sh-bash
>>>> provides=('sh')
>>>> depends=('bash')
>>>> conflicts=('sh-dash')
>>>> sh-dash
>>>> provides=('sh')
>>>> depends=('dash')
>>>> conflicts=('sh-bash')
>>>> bash
>>>> depends('sh')
>>>> dash
>>>> depends('sh')
>>>>
>>>
>>> Sure - or we could have a system to handle it in a less obtuse manner...
>>>
>>> What happens when a new package wants to provide "sh"? We need to
>>> rebuild sh-bash and sh-dash? Easy enough, except that assumes that all
>>> three packages are packaged by the same group. If bash and dash are
>>> packaged by a distro and the new package by a third party, then the
>>> conflicts provided by the distro are not enough. But an alternatives
>>> system would work.
>>
>> 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.
