Em ter., 24 de jun. de 2025 às 07:07, Aoife Moloney via devel-announce <devel-annou...@lists.fedoraproject.org> escreveu: > > Wiki - https://fedoraproject.org/wiki/Changes/Drop_i686_support > Discussion thread - > https://discussion.fedoraproject.org/t/f43-change-proposal-drop-i686-support-system-wide/156324 > > 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 == > > * Name: [[User:Decathorpe| Fabio Valentini]], [[User:Fale|Fale]], > [[User:Kevin|Kevin Fenzi]] > * Email: decathorpe (at) gmail (dot) com, mail (at) fale (dot) io, > kevin (at) scrye (dot) com > > > > == Detailed Description == > > Fedora stopped providing > [https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels > kernel packages, installer images] and stopped publishing > [https://fedoraproject.org/wiki/Changes/Noi686Repositories 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 > [https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval 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 > [https://src.fedoraproject.org/rpms/wine/pull-request/19 "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: [https://pagure.io/releng/issue/12782 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 > >
Dropping i686 support and the Steam problem is interesting for me because I see it like this: Steam games shouldn't be affected but the Steam client will be. Essentially Steam has 3 current runtimes: Steam Linux Runtime 1.0, 2.0 and 3.0, each one slightly newer than the previous and apparently based on a specific Debian release. You can read more about the runtimes here: https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/container-runtime.md If I understood correctly the 1.0 runtime is based on 2.0 with a LD_LIBRARY_PATH, while the 3.0 has to be setup by game developer. Also 2.0 and 3.0 are used as a base for Proton compatibility layers. Why is that relevant? While currently most games probably run using the host libraries (either actual host or the feedesktop runtime in case of Flatpaks), there's nothing preventing every game from being set to a runtime so we don't have to depend on host libs at all. The problem now is that the Steam client itself apparently relies on the 32-bits for some reason, which I'm not sure why. If you think about it those are the main components of Steam: * The Steam client which uses CEF for its UI * Steam Overlay * Steam chat (includes voice chat) * Steam Game Recording IMHO the way Valve can fix this: * For games, Valve should either nudge devs into using the SLR 3.0 if possible, otherwise they should automatically set games without a explicit runtime to SLR 1.0 and only revert if it breaks something * For the client, Valve should get around to finally porting it to 64-bits, I guess they only did it on MacOS when 32-bits support got taken away, so it's the same case If neither can be done, probably Flatpak is the remaining choice. The only game I ever had an issue under Flatpak that couldn't be fixed due to the sandbox was OneShot (since some game behavior would rely on breaking the sandbox), but the World Machine Edition probably workarounds those issues. > -- > Aoife Moloney > > Fedora Operations Architect > > Fedora Project > > Matrix: @amoloney:fedora.im > > IRC: amoloney > > -- > _______________________________________________ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue Good luck all, Mateus Rodrigues Costa -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
