[pacman-dev] Alternatives system brainstorm

[Daan van Rossum]

* 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
1. alternatives
2. env-modules
and that when talking about support for alternatives it may be helpful to clearly differentiate between these two[*], like Fedora does as well[1].


* 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:
	requires=('awk-provider')
	alternative_providers=('gawk' 'nawk')  # for hinting only, may be incomplete!


Provider package 'gawk' specifies
	selector=('awk')
	provides=('awk-provider')
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: [1] gnu-netcat, [2] openbsd-netcat.


Best, Daan


[*] 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.

[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20191023/29b808c5/attachment.sig>