New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/pull/24357#issuecomment-676835665

Comment:
> I don't quite get what you mean. These other things are unnessecary, and the shorthand for `nodebug`, etc is useful for data packages. This is why I think we should rename it.

That a package is `noarch` implies that it has no native executables (which I am distinguishing from text files that are parsed by an interpreter and have an execute bit set). That a package has no native executables implies that we can set `nodebug` and `nostrip`. Transitively, `noarch` implies these things too, but if we're going to lop out the core functionality invoked by `noarch`, we shouldn't keep some vestigial keyword around just for convenience.

Keeping a `noarch` keyword without supporting `noarch` packages, where `noarch` is a wildcard for the package manager, is just misdirection. The right way to signal that we don't need to debug or strip anything is to add a `noexecutable` flag or something similarly named, or else just add the individual flags to templates. Calling it `noarch` is just going to lead to confusion, and keeping `archs=noarch` produces unexpected results because it has specific meaning now.

I haven't thought about package dependency graphs and don't much care to. In principle, it doesn't seem like properly supporting `noarch` in dependency resolution (and it seems to me the repo-maintenance challenges are just dependency resolution across the architecture dimension) should be too challenging, but I can certainly believe that difficulties in the implementation quickly become more trouble than they are worth to save some disk space.

If that's the case, drop `noarch` from XBPS, modify `xbps-src` to treat `archs=noarch` as `noexecutable=yes` and emit a warning about this transitional reinterpretation, modify `xlint` to complain when `arches=noarch` is detected and recommend the new keyword, and once we've rebuilt every `noarch` package with `noexecutable=yes` instead, drop these transitional modifications. Or just bite the bullet, migrate every template in one pass and be done with it.