[pacman-dev] Alternatives system brainstorm

[Allan McRae]

On 23/10/19 9:35 pm, Daan van Rossum wrote:
> * 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

<snip>

> 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...

Allan