* on Monday, 2019-11-04 12:39 -0500, Eli Schwartz <[email protected]> wrote:
> 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 Then you end up with package lua52 that provides lua, and a package lua providing lua53. Ugly! > <snip> > 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. Pacman already doesn't stop a user from having python point to whatever the user wants. Arch users know that but does pacman also need to support OSes where users don't know that? That brings up another idea: why does pacman not provide alternatives via managing symlinks in /usr/local (or even /usr/alternatives)? That would be entirely independent of the current package structure. If a user doesn't set alternatives then /usr/local remains empty. This would also support the ability to select alternatives per-file etc. as was pointed out by Andrew. I guess a simple version of this could as well be a separate tool instead of part of pacman, except that no comprehensive alternatives info would be available to the user. But do users really need that? I think a user that wants to set an alternative knows what he/she wants to do. The simplest version of this is to let the user manage these links manually :) Daan
signature.asc
Description: PGP signature
