On 11/4/19 12:06 PM, Daan van Rossum wrote:
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.
My expectation is it installs what it does today, the "lua" package which provides /usr/bin/lua5.3 and now, instead of installing /usr/bin/lua, installs an alternative that is fulfilled by default for /usr/bin/lua5.3 I suppose I see your point w.r.t. updating the package, does updating lua 5.3.5-2 to lua 5.4.0-1 keep the symlink, updating it to point to /usr/bin/lua5.4, but I don't see why it needs to change how we name packages and we're under no obligation to rename 'extra/python' to 'extra/python3' and have it merely provide 'python'. We can and should continue to make `pacman -S python lua` install the preferred forms of the package.
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)!
I think it's fine to have pacman -S python install python3, and have there be a very high likelihood that /usr/bin/python points to python3. This doesn't mean we need to stop people from switching it if they really want to. python 3.x will be installed first in most cases, because much more common software depends on python3 these days than on python2, including many core desktop environment components.
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.
Do you really think gawk/nawk is all as simple as that -- consider makepkg, which depends on awk, but "Results may be inaccurate when using a broken implementation of awk, such as mawk or busybox awk." Thankfully we don't package mawk, we do package busybox awk though. Either gawk or nawk would work, but do we force people to use gawk? There's no such thing as /usr/bin/nontrashy-awk. Opinions, opinions, opinions everywhere. You'll always be able to find something objectionable about making any tool selectable, so let's not take sides and say python is less deserving than awk. :) -- Eli Schwartz Bug Wrangler and Trusted User