F44 Change Proposal: Drop i686 support (system wide)

Project Discussion Change Proposals
,
1

Drop 32-bit multilib support on x86_64 and stop building packages for i686

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.

Wiki
Announced

:link: Summary

Fedora package repositories for the x86_64 architecture no longer include libraries for compatibility with 32-bit applications (“multilib”), and packages are no longer built for the i686 architecture.

:link: Owner

:link: Detailed Description

Fedora stopped providing kernel packages, installer images and stopped publishing i686 package repositories with Fedora 31. However, packages were by default still built for the i686 architecture, since they were required for running 32-bit applications on x86_64 hosts (“multilib”).

Since Fedora 37, leaf packages (i.e. packages that are not depended on by other packages) can simply stop building for i686 without any reason, which has allowed package maintainers to focus their work on architectures where packages are actually shipped to users.

This Change Proposal implements the next two (and last) steps:

  • Packages built for the i686 architecture are no longer included in x86_64 repositories (dropping “multilib” support, i.e. support for running 32-bit userspace on a 64-bit host).
  • Packages are no longer built for the i686 architecture.

This is intentionally planned as a two-step process - the first step (no longer including 32-bit libraries in the x86_64 repositories) should be relatively easy to revert (if needed). The second step is basically irreversible, since reversing it would require to partially re-bootstrap the architecture.

Some packages will require changes to adapt for the removal of 32-bit libraries from the x86_64 package repositories - notably, wine will need to be built in the “new WoW64” configuration, which allows running 32-bit Windows applications on top of 64-bit-only host systems.

It is planned to implement the first step as early as possible in the development cycle, but before the mass rebuild at the latest. This provides a transition period of at least four weeks to catch potential issues before the potentially irreversible second step is implemented (before the beta freeze).

When this Change is successfully implemented, a mechanism will be provided to remove any installed i686 packages on upgrade to avoid leaving behind packages that will no longer be updated, maintained, or which might cause upgrade issues in the future.

:link: Feedback

N/Y

:link: Benefit to Fedora

By dropping completely the i686 architecture, Fedora will decrease the burden on package maintainers, release engineering, infrastructure, and users.

:link: Package Maintainers

Building and maintaining packages for i686 (and 32-bit architectures in general, but i686 is the last 32-bit architecture - partially - supported by Fedora) has been requiring more and more effort.

Many projects have already been officially dropping support for building and / or running on 32-bit architectures, requiring either adding back support for this architecture downstream in Fedora, or requiring packaging changes in a significant number of packages to adapt to this dropped support.

By dropping support for the i686 architecture entirely, this additional - and growing - maintenance burden is eliminated.

:link: Release engineering

The process for including 32-bit libraries in the x86_64 repositories is based on brittle heuristics and rules, which can be removed when this change is implemented - simplifying the process for creating x86_64 package repositories.

:link: Infrastructure

No longer building packages for the i686 architecture frees up resources on x86 build machines that will instead be available to speed up x86_64 package builds.

:link: Users

By dropping ~10000 32-bit packages from the x86_64 repositories, repository metadata will get smaller, which should speed up both metadata downloads and any dnf operations that involve dependency resolution.

:link: Scope

  • Proposal owners:

    • Prepare compose configuration changes to drop multilib support from x86_64 repositories.
    • Prepare builder configuration changes to drop the i686 architecture from the f44 build target.

  • Other developers:

    • Adapt packages for the removal of 32-bit libraries from the x86_64 package repositories.
    • Potentially simplify ExcludeArch / ExclusiveArch usage and / or %__isa_bits conditionals in spec files.

  • Release engineering: releng#12782

    • Review and deploy compose configuration changes.
    • Review and deploy builder configuration changes.

  • Policies and guidelines:

    • Drop mentions of i686 architecture support from documentation (Packaging Guidelines, …).

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy: :shrug:

:link: Upgrade/compatibility impact

Any 32-bit packages installed on x86_64 systems should get removed on upgrade, and will no longer be available from package repositories. Any third-party software that depends on these 32-bit libraries will no longer be installable on Fedora. Wine prefixes created on older versions of Fedora might need to be recreated.

:link: How To Test

Upgrading to the Fedora version that implements this change should remove any 32-bit packages from x86_64 systems, and no packages for the i686 architecture should be available from the x86_64 package repositories.

Installing and using Wine to run Windows applications should continue to work, but Wine prefixes created on older versions of Fedora and / or with older versions of Wine might need to be re-created.

:link: User Experience

  • Package repositories no longer include i686 packages for compatibility with 32-bit applications. Third-party RPM packages that do not provide 64-bit versions for x86 will no longer be installable.
  • Package repositories no longer include i686 packages for compatibility with 32-bit applications. Package management operations (GNOME Software, Discover, DNF, etc.) should be faster, including metadata downloads and dependency resolution.

:link: Dependencies

  • wine: build package with “new WoW64” mode enabled
  • steam: adapt or drop RPM package from default third-party repositories

:link: Contingency Plan

  • Contingency mechanism:

    • If only step one has been implemented, Release Engineering needs to revert the compose configuration changes to restore “multilib” support (i.e. include 32-bit compatibility libraires in x86_64 repositories again).
    • If both step one and two have already been implemented, reverting the changes would require re-bostrapping the architecture, which would be difficult to justify.

  • Contingency deadline: Beta Freeze

  • Blocks release? Yes (Change is either fully implemented or reverted)

:link: Documentation

TODO

:link: Release Notes

TODO

Last edited by @amoloney 2025-06-24T10:41:23Z

Last edited by @amoloney 2025-06-24T10:41:23Z

5 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.

3 Likes
3

@amoloney This is a CP for F44 (or later), not F43 - I’ve updated the title accordingly, but I couldn’t update the tag from f43 to f44 because the latter doesn’t exist yet - can you help me with that please?

2 Likes
4

Sorry, I was on autopilot :frowning: yep Ill take care of that and add a reply to the devel-announce post too.

3 Likes
6

Will this impact packaging of Steam on RPMfusion?

9 Likes
7

This effectively breaks the FEX rootfs we have been producing since Fedora Linux 42 for x86 emulation on aarch64.

We rely on being able to include x86_64 and i686 libraries to produce a Linux environment that’s viable for gaming on Linux ARM machines. The image definition outlines exactly what we’re pulling in right now.

I would prefer not to do this or flip the mechanism so that we can select packages to be i686 eligible for builds in Koji (perhaps with another build tag or a flag or something).

29 Likes
8

If this Change is implemented, can I still use podman/docker/toolbx containers with 32bit (or 64bit multilib) OSes to run old native apps/games [1] on Fedora?

[1] or even certain Wine games, because some games seem incompatible with WoW64

What about Wine/Steam/etc Flatpaks with 32bit libs included, will those work?

6 Likes
9

@barryascott, it’ll impact Fedora’s support for it: [1]

steam: adapt or drop RPM package from default third-party repositories.

I seriously suggest that everyone upvote steam-for-linux/issues/3518:

It’s one of those corporate issues that’ll solely be remediated via advocacy.

  1. fedoraproject.org/w/index.php?title=Changes/Drop_i686_support&oldid=743009#Dependencies ↩︎

2 Likes
10

I am concerned this will cause significant issues for gamers on Fedora and distributions based on it, e.g. Bazzite and Nobara. As such, I’m against any change that will break old Linux game binaries, Steam, and 32-bit Windows games not using Wine’s new WoW64 support, but instead a 32-bit Wine prefix (for better performance and compatibility). This will also break Steam on Fedora Asahi remix.

21 Likes
12

This isn’t explicitly mentioned in the Change Proposal, but a workaround for Steam (if it isn’t updated to run on 64-bit only systems) would be to use the Flatpak, which includes the necessary 32-bit libraries. It has some limitations compared to a “native” RPM package, but not nearly as many as there used to be.

I’ve been running the Steam Flatpak for gaming exclusively for years, and haven’t hit any flatpak-specific issues. A few days ago I did more testing for controller support (since that was apparently one of the reasons for using the RPM over the Flatpak), and found that all controllers I easily had access to worked out of the box - Switch Pro controller wired via USB, and DualShock 4 both via USB and BlueTooth.

9 Likes
13

I’d prefer my legacy games and applications continue working on Fedora without the need to flatpak/containerise everything. Strongly opposed to this.

15 Likes
14

This is why it’s a proposal, and why I filed it more than 6 months earlier than strictly required.

But just to clarify - we will need to drop support for 32-bit x86 at some point. It’s dead, and more and more software just doesn’t support being built and / or run in 32-bit environments at all.

Yes, some things will stop working. But I hope that we can provide solutions and / or workarounds for most use cases.

And it’s better to start planning for the removal of i686 packages now than when (insert foundational package here - for example, CPython) stops supporting 32-bit architectures and we need to scramble to adapt.

15 Likes
15

As I understand it, Steam VR does not work with the Flatpak at all.

7 Likes
16

“Yes, some things will stop working.”

90% of native linux games created before mid 2010s and still some more created today and some windows games that don’t work in WOW64 wine mode will stop working without annoying distrobox tinkering that the average user doesn’t want to deal with.

13 Likes
17

Yes - time passes, things change. Surprise! :sweat_smile:

I assume at some point 32-bit-only native Linux games will be treated similar to other “retro” games, i.e. require emulation or a separate runtime. We can’t keep supporting “legacy” stuff indefinitely, it’s a constant burden on Fedora server infrastructure and package maintainers.

5 Likes
18

When Ubuntu proposed this, they came up with a solution to just build the packages needed for Steam and older Linux games for 32-bit architectures. Statement on 32-bit i386 packages for Ubuntu 19.10 and 20.04 LTS

I think something like this woulld be acceptable here.

18 Likes
19

Why does Windows keep supporting 32-bit but Fedora can’t?

Both are maintained by large companies.

1 Like
20

We have thought about this, but it would be quite difficult to implement in our build pipeline - we handle architecture support entirely as opt-out, which makes an opt-in list for i686 hard.

2 Likes
21

This would negatively impact downstream distributions like Bazzite.

In order for Gamescope to function properly, Steam (and it’s dependencies) need to be packaged as an RPM. Flatpak steam would not work as an alternative.

Also for anyone who relies on wine to play legacy games, they would also be negatively impacted.

I am all for trying to remove technical debt, but if there is an option for an exclusion list for important packages rather than a blanket policy, that might help ease the transition.

28 Likes