fix(libc): 'gnu' should never mean 'none' on 'linux'

[coolaj86]

Problem

bat has packages that are explicitly marked as gnu, but are being erroneously detected as libc:none, the same as the musl packages.

History

Unexpectedly, gnu is a very ambiguous term. It's usually only used to identify windows packages as non-msvc (libc:none), or some specific build of arm (e.g. el, hf).

Linux is implicitly gnu if not explicitly musl (Alpine) or bionic (Android).

However, many modern tools don't use gnu (i.e. Go, Zig), so when not specified Linux is implicitly none.

HOWEVER, when Linux specifies gnu, it's explicitly libc:gnu, not libc:none.

Solution

Since this would currently be the only member of a 3rd tier terms list, it's instead added as a special case for identifying the architecture of a package.

Other considerations

This is tricky no matter which way we slice it because some musl packages rely on musl's libc++ (such as node.js), so we can't just mark all musl packages as libc:musl and have libc:musl preferred over libc:none or libc:gnu automatically.

Likewise, explicit gnu packages almost always linking against other gnu packages (at least libc) and almost never work on musl.

There's also the possibility to detect that if one package is marked as musl and another is not marked as gnu that we could cross-compare packages to mark it as gnu. However, I think that's too complex - that type of tagging should just be handled in the installer's releases.js itself.