F45 Change Proposal: Build x86-64-v3 Packages [SystemWide]

Project Discussion Change Proposals
, ,
1

Build x86-64-v3 Packages

Wiki

Announced

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary :open_book:

Build x86_64_v3 packages in addition to the current x86_64_v1 builds.

Owner :open_book:

Detailed Description :open_book:

This change would introduce a new primary architecture, x86_64_v3. Existing packages built for x86_64 would start being built for v3. The support for installing x86_64 microarch packages are already in libsolv and RPM, but will require changes in DNF and Koji.

Feedback :open_book:

No feedback at this moment.

Benefit to Fedora :open_book:

This change allows installing packages compiled against a more recent x86_64 baseline, which can improve system performance for modern machines.

Scope :open_book:

  • Proposal owners:
    ** Extend Koji to support x86_64 architecture levels
    ** Add compiler flag definitions for x86_64_v2/v3/v4 to redhat-rpm-config
    ** Add support to DNF5 to transparently use packages for higher levels as appropriate
    ** Add support to Pungi for x86_64 architecture levels to x86_64 composes
  • Other developers:
    ** Release Engineering: Enable and deliver x86_64_v3 repositories and images for x86_64
  • Release engineering: [Making sure you're not a bot! #13310]
  • Policies and guidelines: Packaging guidelines need to be updated to note %{x86_64} should be used for architecture conditionals for x86_64 instead of just the plain x86_64.
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with the Fedora Strategy: Building microarchitecture packages for modern systems helps Fedora lead in distribution development. However, this change does not align with any specific objective.

Upgrade/compatibility impact :open_book:

On upgrade, systems that have support for the x86_64_v3 baseline will automatically install x86_64_v3 packages when available.

Early Testing (Optional) :open_book:

Do you require ‘QA Blueprint’ support? N

How To Test :open_book:

To test, a x86_64 system supporting the v3 baseline is required. When available, DNF will select packages with the highest compatible baseline. Testing involves upgrading or installing 45 on a supported system, ensuring that packages installed are compiled for the x86_64_v3 baseline, and validating that packages built for v3 work as expected.

User Experience :open_book:

Packages compiled against a higher baseline may perform better on systems which support it.

Dependencies :open_book:

koji, redhat-rpm-config, pungi, dnf5.

Contingency Plan :open_book:

  • Contingency mechanism: Revert and unpublish x86_64_v3 packages and defer to the next release.
  • Contingency deadline: Beta Freeze
  • Blocks release? No

Documentation :open_book:

There’s no current upstream documentation for microarch handling in DNF, but for reference, these PRs may be useful:

Release Notes :open_book:

\n\n\nFedora now provides packages for the x86_64 v3 baseline. When upgrading the system to Fedora 45, DNF will pull packages for x86_64 v3 if the host system is detected as supporting a x86_64 v3 or higher baseline. This may improve system performance on modern machines.

Last edited by @alking 2026-04-14T14:00:51Z

Last edited by @alking 2026-04-14T14:00:51Z

6 Likes
2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

2 Likes
3

My primary question is whether we have enough Infra resources to do this.

3 Likes
4

We probably do from an x86_64 perspective. If we were talking about the other architectures, doing a secondary architecture build is probably infeasible at this time.

We already build the whole x86_64 set for x86_64-v3 in ELN, so we know that it “works” already.

1 Like
5

DNF (and any other tooling) will need to be able be configured to not to use the higher micro-architectural levels (use cases I can envision include building on machine A to move boot disk to machine B, or, the somewhat equivalent, building a VM that needs to be able to be live migrated to another system that does not support higher micro-architectures).

3 Likes
6

Will COPR also be updated to support parallel micro-architectures, or will it only build -v1?

1 Like
7

Would only a subset of packages be rebuild or all of them?

8

I suppose we will use x86_64 (v1) packages to bootstrap this. So the x86_64-v3 buildroot should inherit from the plain x86_64 one. Correct? Can we do that in Koji?

Similarly, in real mirrored repos. On a x86_64-v3 compatible machine, will I only have one repo that contains both x86_64-v3 and v1 packages, or will I have two repos?

9

I’m not very in favor of this plan. It seems like a massive waste of resources for little gain. By this I mean:

  • disk space for all the 23,000 duplicated packages
  • cpu time to build all those packages
  • cpu time/disk space to compose all those packages
  • bandwith to sync and mirror all those packages
  • mental capacity / websites to explain to users what to get

My personal ordering of how to handle this best would be:

  1. Each application would detect at runtime what features are available and run based on that. Sadly, we don’t live in a world where this is really easy to do for them and most probibly don’t bother.
  2. If that fails, I would prefer something like the already approved f42 change: Changes/Optimized Binaries for the AMD64 Architecture v2 - Fedora Project Wiki being extended to support those specific packages that could gain advantage from v3.

I am curious about some of the other questions already posed by others (is this all packages, how do repos interact, etc).

3 Likes
10

I would note that, while Changes/Optimized Binaries for the AMD64 Architecture v2 - Fedora Project Wiki was approved for F42, it appears that the proposal was never actually implemented.

3 Likes
11

If the owners of this change helps, then yes.

But it needs some work:

  • Check if Pulp’s publish-repo works with two packages of the same NEVRA in the same repo (hint: likely no)
  • Amend Copr code that prune old data and keep only one highest NEVRA.
  • Amend Copr code to submit two build for one chroots. (That will not be easy)
12

Drop v1 and only ship v3 if infra is an issue!

13

Micro-architectures in RPM are already separate architectures. Mock has also been enhanced thanks to AlmaLinux. No COPR work required.

This is not viable. It creates a permanent security vulnerability for applications because there is no secure way to avoid “path hacking”. We also don’t have a way to do selective architecture enablement for packages at the Koji level, or we would have already done it for 32-bit x86.

That Change also was never implemented.

The NEVRA would be different, as x86_64 and x86_64_v3 are separate RPM architectures. You already know this because AlmaLinux does the reverse: x86_64 (meaning RHEL v3) and x86_64_v2 (real v2).

Why would that be needed? Just make another chroot entry and be done with it. Copr doesn’t behave like Koji already, no need to change that now.

This is for all of them, as the Change describes.

3 Likes
14

That patch is a result of a misunderstanding, though. It seems like Podman isn’t working well on x86_64_v2 systems.

15

Let’s not. More than 5% of users in the latest Steam hardware survey lacked AVX2, and gamers as a group likely have newer hardware than general users. Intel was still launching new desktop chips without AVX2 as recently as at least 2020.

4 Likes
16

I don’t think it’s fair to hold back newer CPU’s users just because 5% of users don’t have support.

This subject has been shelved many times before, if it gets rejected, maybe I will switch to a distro that has proper support for my hardware.

2 Likes
17

I don’t think there is one. I don’t know why you think there is one. Enhancing Podman to autoselect variants would be nice, but the behavior isn’t specified in OCI. And with the notable exception of RHEL, everyone agrees that x86_64/amd64 should mean v1, so it’s a safe default if you don’t specify anything from an upstream Podman/Docker perspective.

Even if the autoselection stuff existed, it would still do the wrong thing for RHEL-like systems because RHEL didn’t do the bump to x86_64-v3 properly. And we’d still need a way to force the right bootstrap root to be downloaded.

18

Aha. Then I misunderstood the implementation. So users will have two configs for one project? One with x86_64 and the second with x86_64_v3? Then we will need to alter dnf-plugins-core.

19

Pretty much a tangent, but as I did not carefully follow how it was done in RHEL (just making sure all relevant systems were -v3 capable once the announcement of the requirement was made) I am curious as to what RH did wrong, and how it could have been done better?

20

Red Hat Enterprise Linux applied the x86_64-v3 flags to the x86_64 architecture. The problem with this is that libsolv and RPM cannot detect that the packages may be incompatible with your system, since that relies on the correct architecture label being used to tell RPM to check.

This means there’s no way for someone to figure out that it’s not going to work until it crashes on them. Same for in Mock or other places where v3 masquerades as v1.