[pacman-dev] Alternatives system brainstorm

Allan McRae allan at archlinux.org
Mon Nov 4 22:12:32 UTC 2019


On 5/11/19 7:40 am, Daan van Rossum wrote:
> * on Monday, 2019-11-04 12:39 -0500, Eli Schwartz <eschwartz at 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


More information about the pacman-dev mailing list