Is there any more context behind this? If we're going to stick some ad-hoc arch mangling in a place like this I'd like for our future selves to be able to figure out why.

(e.g. a bz number, link to a discussion, etc)

the commit comment explains it some. It came about by my testing of making docker base images. The rpm arches for hardware floating point are completely made up as the real arches were taken by software floating point

It feels like this logic should be in ImageFactory.

We're passing in the arch parameter, why don't we just pass in the correct value to begin with? Or is there a reason the Koji arch parameter needs to be different than what we pass to ImageFactory? Maybe we need a separate imgfac_arch parameter?

So, factory/Oz wants an arch that can be used in libvirt XML which I believe inherits from some canonical architecture naming standard in qemu and related tools.

I believe Dennis' patch is a reasonable approach here, as it is in an RPM-centric tool (koji) and is owning the translation between RPM architecture naming and the virt-centric package-agnostic architecture naming scheme used by Oz/Qemu.

the arch parramater we put in the TDL file has to be valid for qemu. in the case of arm there is two sets of arches that rpm has that can run on 32 bit arm hardware. as far as rpm and koji is concerned. arm7vl is 32 bit armv7 with software floating point. armhfp is the basearch used in yum/dnf armv7hnl and armv7hl arm rpm arches that define armv7 with hardware floating point 7hnl specifies that there is a neon floating point unit. The kernel makes no difference between what userland is running and always reports the arch as armv7l with the l being for little endian uname -m will always report armv7l so i think the right thing for us is to pass on the correct value

@mikem ping, is there any issue with this? it clearly only effects arm.

pulling in (with rebase)