* on Wednesday, 2019-10-23 22:05 +1000, Allan McRae firstname.lastname@example.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 always 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 about 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.
Sure, the Arch devs that decided that python3 was more appropriate to follow for a bleeding edge distro like Arch than python2 might not have met everyone's choice, but it is something that users can easily work with (as evidenced by the fact that env-modules lives in AUR)!
Supporting alternative upstreams such as nawk <-> gawk is all different in my view; easy to support and nice to have. IMHO it would stress the beauty and power of Arch/pacman if it is able to support such alternatives without the need of a fully-fledged alternatives system.