[pacman-dev] Alternatives system brainstorm
Daan van Rossum
d.r.vanrossum at gmx.de
Mon Nov 4 17:06:04 UTC 2019
* 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 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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: not available
More information about the pacman-dev