[pacman-dev] Alternatives system brainstorm

Levente Polyak anthraxx at archlinux.org
Mon Nov 4 17:19:17 UTC 2019

On November 4, 2019 6:06:04 PM GMT+01:00, Daan van Rossum <d.r.vanrossum at gmx.de> wrote:
>* on Wednesday, 2019-10-23 22:05 +1000, Allan McRae
><allan at archlinux.org> wrote:
>> On 23/10/19 9:35 pm, Daan van Rossum wrote:
>> > [*] IMHO it is one of Arch's strengths to follow upstream as much
>as possible and settle on a single current version of e.g. Python. 
>Older versions can be installed but the '/usr/bin/python' is always
>what upstream deems 'current'.  
>> Upstream python specifically states that /usr/bin/python should
>> point to /usr/bin/python2.  So Arch does not follow upstream in that
>> regard.  Just some idiot decided it was time to point to python3
>> 10 years before upstream will...
>Given the alternatives system you, Allan, suggest.  What if a user runs
>	# pacman -S lua
>, will you print a list of alternatives for a user to choose from?
>Suppose you do that, and present the options
>	1. lua53
>	2. lua52
>	3. lua51
>and the user choose lua53, now what happens when lua54 is released
>upstream?  I was happy with pacman giving me the latest upstream and in
>peace with it following upstream.
>One concern I would like to share is that introducing alternatives for
>managing parallel "versions" of the same tool may impact how KISS
>Arch/pacman is going to be.

What exactly forbids people to still name the non pin-versioned variant
lua as it today is the case in Arch? 

More information about the pacman-dev mailing list