get_buildarch may give the wrong answer if repo contains multiple compatible arches

[AdamWill]

See silverblue issue #67 for this. Basically, we traced a Silverblue installer build fail down to pungi not passing --buildarch to lorax, which causes lorax to fall back on the get_buildarch() mechanism in pylorax/__init__.py, which attempts to detect the buildarch by looking at the arch of the first available non-source anaconda-core package in whatever repositories it's been configured with.

This worked fine until we changed pungi to use different repos for the ostree-installer composes; it uses the 'work' repo, now, not the 'Everything' repo. The x86_64 'work' repo contains all i686 packages as well as all x86_64 packages (it doesn't just contain multilib i686 packages). So there are two available non-source anaconda-core packages when this detection is run, i686 and x86_64. If it happens to run into the i686 one first (which it seems it always does - presumably some alphabetical sorting going on somewhere), it'll decide the buildarch is i686, not x86_64.

To fix this for Fedora composes we're just going to have pungi pass --buildarch to lorax, there's no good reason it hasn't been doing that all along. So fixing this isn't urgent. But it still seemed worth logging an issue for the problem in lorax, since it's still potentially there.

Perhaps this get_buildarch could just be ditched and passing --buildarch could be compulsory? Or is there a reason we don't want to do that?

It is possible to fix this, of course, but I couldn't find an elegant fix quickly (i.e. not just relying on some dumb inline dict of multilib arch lists or something). I couldn't immediately find a handy interface to known multilib cases in dnf or libdnf or anything.

[bcl]

I don't want to require --buildarch for every user, in many cases it is being run against repos with a single arch, and I'm reluctant to change existing behavior. I think it's reasonable to require that users pointing to repos with multiple arches tell lorax which one to use.

In order of preference I could:

• detect multiple arches and log what was found and what the decision was (sort and pick first one?)
• detect multiple arches and exit with an error, requiring --buildarch to be passed to select one of them.

[AdamWill]

The 'sorting' is the tricky part. I mean, my idea was that there must be a reference of known multilib sets somewhere with the 'native' arch identified, so in theory we should be able to do this magically at least for multilib cases (we can't help the case where someone just puts a bunch of differently-arched packages in a repo for the hell of it or something). But I couldn't actually find such a neat reference in any lib lorax might reasonably use, and it seemed wrong to just write it into lorax. I dunno if I missed something there, though.

[bcl]

I'm going to close this for now, I haven't seen any other reports of this and pungi seems to have solved it about as elegantly as we can hope for :)