From Fedora Project Wiki


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.

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.

Owner

Current status



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.

Feedback

N/Y

Benefit to Fedora

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

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.

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.

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.

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.

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:

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.

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.

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.

Dependencies

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

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)

Documentation

TODO

Release Notes

TODO