This is a follow-up from yesterday’s FESCo meeting (look for “primary arches” in the meeting log). The current documentation for what makes an architecture “primary” vs. “alternative” (or “secondary”) seems to be outdated and needs some rework.
Two tiers of architectures
Let’s see what we have today. Quoting from the structure section of the architectures wiki:
There are two tiers of architectures with Fedora support:
Primary Architectures : These are architectures with the majority of
the users, the most common architectures. Build failures on these
architectures are fatal: no packages push to the repositories if
they fail to build for a primary architecture. Fedora package
maintainers are required to make sure that their package builds
properly for this architecture (or is properly ExcludeArch'd).
Alternative Architectures : These are architectures with motivated
Architecture Maintainer Teams. There are two classes of Alternative
Architecturs, the ones built in Primary koji where build failures
are fatal and ones built on their own koji instances where build
failures on the alternative architecture are not fatal: if packages
successfully build for the primary koji, they push independently of
any alternative architecture build successes or failures.
The main takeway from the above is that for “primary” architectures, the build failures block main deliverables, while alternative arches don’t.
Elsewhere on Fedora Matrix, @kevin explained that there was a time where an
architecture was “primary” for some deliverables and “secondary” for others, which muddies the waters further.
The aim of this thread is to dispel this confusion and bring some clarity based on current practices. Once the dust settles, update the architectures documentation.
PS: This is also cross-posted to the ‘fedora-devel’ list.
I always found this classification less than helpful and mostly confusing.
For package maintainers, there is no difference between a “Primary” architecture and an “Alternative” architecture that is also built in the “primary” koji - if a package build fails on any of the architectures in either group, the build is marked as “failed”.
So to me this has always seemed as if it is kind of mixing 1) “marketing” terms with 2) technical / implementation differences and 3) QA guarantees, and creates a confusing classification that isn’t quite correct from any of the three viewpoints. Maybe it would make sense to classify architectures on those three axes separately, not creating a pseudo-classification that doesn’t fit any of them?
For package maintainers, there is no difference between a “Primary” architecture and an “Alternative” architecture that is also built in the “primary” koji - if a package build fails on any of the architectures in either group, the build is marked as “failed”.
Yeah, I agree that it’s effectively the same from a packager perspective.
So to me this has always seemed as if it is kind of mixing 1) “marketing” terms with 2) technical / implementation differences and 3) QA guarantees, and creates a confusing classification that isn’t quite correct from any of the three viewpoints. Maybe it would make sense to classify architectures on those three axes separately, not creating a pseudo-classification that doesn’t fit any of them?
I’m a bit torn, while what you say will reflect reality more accurately, “someone” has to keep all of this in sync.
We also dropped ARMv7 in Fedora 37, Changes/RetireARMv7 - Fedora Project Wiki, but your point that “primary” architecture changes are rare occurrences remains valid.
