* on Sunday, 2019-10-20 21:05 +1000, Allan McRae <al...@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 <al...@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/
signature.asc
Description: PGP signature
