It's not quite clear to me what a user should expect here.

You've included both:

• x86_64 in x86_64_v2
• x86_64_v2 in x86_64

Both entries have the same arches listed in the same order. What is the expected difference between asking for a dist-repo for x86_64 and for x86_64_v2?

In Fedora 42, they are making x86_64_v2 the baseline (so x86_64 rpm files will be v2). Similarly RHEL made this change in version 9. Of course, other distros do things differently.

https://discussion.fedoraproject.org/t/f42-change-proposal-optimized-binaries-for-the-amd64-x86-64-architecture-v2-self-contained/142032

We're trying to use AlmaLinux 10 as the source, which has both x86_64 and x86_64_v2, but as separate repos: https://mirror.fcix.net/almalinux/10/BaseOS/

We're trying to stay compatible with v2 so we'd like to use x86_64_v2 as the base, but that means we have to make the arch of our own tag "x86_64_v2", otherwise our external repo definitions do not work (because of the $arch substitution). I added x86_64_v2 to the x86_64 list because I'd consider them compatible, and I added x86_64 to the x86_64_v2 list because I was looking at what you were doing for "i386". Would something else be more appropriate?

It's complicated because different groups are handling this different ways. Some are raising the baseline so that arch=x86_64 means "built for x86_64, presuming at least v2 microarch" (case A), and others are keeping that as "all x86_64" but using a separate arch=x86_64_v2 (case B). And Koji needs to work sanely for both groups.

My initial take is that arch=x86_64 should not include x86_64_v2 as compatible.

• in case A, x86_64_v2 is not used so nothing is lost by leaving it out
• in case B, arch=x86_64 means "backwards compatible to v1", so v2 specific builds are not compatible.

Otoh, in both cases, I do think it makes sense to include x86_64 in the compat list for x86_64_v2

It's worth noting here that that koji.canonArch('x86_64_v2') == 'x86_64_v2', so Koji itself considers this a completely separate arch in terms of performing builds.

In my opinion, RHEL made a mistake by not using the correct arch when lifting up to x86_64-v2/v3. That's what has made a lot of this complicated. Abusing the x86_64 architecture and mixing the -v2/-v3 settings in there has meant the expected way to handle this is broken.

Well that ship has sailed, and micro-architectures are a mess anyway

Anyway, regardless of RHEL's choice to use option A, x86_64_v2 should not be listed as a compatible arch for x86_64 in general. If you can drop that part, then we can move ahead here.

:thumbsup:

Commit 49338e91 fixes this pull-request