[pacman-dev] Alternatives system brainstorm

[Eli Schwartz]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20191104/55e6cfb1/attachment.sig>