On 23/10/19 9:35 pm, Daan van Rossum wrote:
- on Sunday, 2019-10-20 21:05 +1000, Allan McRae email@example.com 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
What if Arch offered alternatives through sets of
Without actually commenting on your idea (because bourbon), I will point out that pacman is distro independent. It just happens that Arch hosts our infrastructure. So our decisions are based around what is best for a package manager, but not Arch.
Now, ignoring my comment about not commenting... My design principle for additions to makepkg is an addition should be mostly straight forward to a packager - i.e. if you can build the software manually, you can package it. Suggestions that look complex to package, are too complex. Looking at your suggestion (admittedly... bourbon), it did not pass my "that seems obvious" threshold.
[*] 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'.
Upstream python specifically states that /usr/bin/python should always point to /usr/bin/python2. So Arch does not follow upstream in that regard. Just some idiot decided it was time to point to python3 about 10 years before upstream will...