Currently we hardcode the architectures the official repos historically supported, which seems both inefficient because of hardcoding, and simply wrong, because many packages support various ARM platforms too. If we were to say "only officially supported arches will be supported in the AUR" we'd have to disable i686, which seems silly and arbitrarily restrictive. Also there's better places to implement such a blacklist (via die_commit in the main loop, via a config option to list supported arches, would make much more sense in terms of logic). As for the metadata extraction itself, there's no reason to hardcode the arches to check for at all. We can get this information too, from the .SRCINFO itself. Detecting this dynamically is not incompatible with a blacklist, should we ever decide to implement such a thing. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> --- Just in case I wasn't obvious, I don't support adding a real blacklist any more than the currently existing accidental sort of kind of one... But currently we're really inconsistent in how we treat e.g. source_aarch64 which just quietly disappears and should really be shown in the web interface. This is extremely valid in -bin packages. It looks like we weren't hardcoding this anywhere but there anyway, the database/frontend don't seem to care what the value of arch is before displaying it. So, no database changes, and less bytes of code. This is a really long commit message and annotation for a two-word change... aurweb/git/update.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/aurweb/git/update.py b/aurweb/git/update.py index da48eb3..0614e9e 100755 --- a/aurweb/git/update.py +++ b/aurweb/git/update.py @@ -39,7 +39,7 @@ def extract_arch_fields(pkginfo, field): for val in pkginfo[field]: values.append({"value": val, "arch": None}) - for arch in ['i686', 'x86_64']: + for arch in pkginfo['arch']: if field + '_' + arch in pkginfo: for val in pkginfo[field + '_' + arch]: values.append({"value": val, "arch": arch}) -- 2.17.0