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

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

 aurweb/git/ | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/aurweb/git/ b/aurweb/git/
index da48eb3..0614e9e 100755
--- a/aurweb/git/
+++ b/aurweb/git/
@@ -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})

Reply via email to