On 5/11/19 7:40 am, Daan van Rossum wrote: > * on Monday, 2019-11-04 12:39 -0500, Eli Schwartz <eschwa...@archlinux.org> > 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?
Yes - pacman is used many places that is not Arch. e.g. Msys2. > 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 :) Sure, you can let a user symlink /usr/local/bin/python -> /usr/bin/python2 and put /usr/local/bin first in the path. But not "man python" does not provide information on what the user sees as the "python" command, and python-config does not point at the python2 version, and ... Simple does not mean half-arsed. Allan