[pacman-dev] Alternatives system brainstorm
Daan van Rossum
d.r.vanrossum at gmx.de
Wed Oct 23 11:35:45 UTC 2019
* on Sunday, 2019-10-20 21:05 +1000, Allan McRae <allan at archlinux.org> wrote:
> It is constructive, but I don't think is necessarily relevant. Pacman
> is a system package manager, not a userspace software manager.
> The HPC use case is quite different. It allows pieces of software to be
> made available to individual users, but not system-wide.
I was under the impression that Arch Linux had gotten around well without both
and that when talking about support for alternatives it may be helpful to clearly differentiate between these two[*], like Fedora does as well.
* on Saturday, 2019-10-19 18:15 +1000, Allan McRae <allan at archlinux.org> wrote:
> The setting of /usr/bin/python is more for interactive use.
The distinction appeared a bit vague to me here. Sorry if misinterpreted!
Back to brainstorming - continuing thoughts shared by Allan, Eli, Andrew, Levente, and others - let me share an idea for a not fully fledged alternatives system (such as Fedora has it) but something more simple that maybe fits nicely in pacman's approach and maybe a bit less obtuse than link packages:
What if Arch offered alternatives through sets of
1. selector package
2. provider packages
Selector package 'awk' owns links in e.g. /usr/bin/ and /usr/share/man that it copied from a fakeroot provided by a provider package under /var/lib/pacman/alternatives/awk/. In addition, it specifies:
alternative_providers=('gawk' 'nawk') # for hinting only, may be incomplete!
Provider package 'gawk' specifies
and a "provide()" function that links the files and directories that it provides to a fakeroot under /var/lib/pacman/alternatives/awk/.
Installing or reinstalling a selector package will detect:
0 providers exist: abort suggesting providers from 'alternative_providers'
1 provider exists: continue silently
>1 providers exist: ask the user to select a provider and continue
Once a provider is selected, its "provide()" function is executed (setting up the fakeroot), and then the selector package is (re-)installed (copying the links from the fakeroot into the system).
Providers that get newly installed on a system trigger reinstalling the selector package, offering the user to switch to the new provider.
Alternatives can be reconfigured at any time by reinstalling the selector package. (But I think this action would be rare on most systems?)
Here are two examples:
# pacman -S awk
-> failed: selector package 'awk' is missing a provider package. Potential providers are: gawk, nawk
# pacman -S netcat gnu-netcat openbsd-netcat
-> select a provider for netcat:  gnu-netcat,  openbsd-netcat.
[*] IMHO it is one of Arch's strengths to follow upstream as much as possible and settle on a single current version of e.g. Python. Older versions can be installed but the '/usr/bin/python' is always what upstream deems 'current'. This implies that old versions are never an "alternative" for new versions in arch's sense. A user can always still depart from this KISS approach in his/her environment.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: not available
More information about the pacman-dev