F44 Change Proposal: Drop i686 support (system wide)

[decathorpe (Fabio Valentini)]

Fedora packages are largely maintained by unpaid volunteers (including myself).

[roidal (roland)]

@decathorpe

Yes - time passes, things change. Surprise!
…
We can’t keep supporting “legacy” stuff indefinitely

Steam is not legacy. In that case i don’t think its appropriate to behave like only “legacy” and decade-old stuff is affected. I would prefere a 64-bit only world too, but as long as there is widely used software requiring 32-bit, i don’t think support should be dropped.

[pizzadude (p d)]

I know that.

But RedHat/IBM sponsor Fedora.

[dmtaylor (Dylan M Taylor)]

He’s right that volunteers are primarily doing the labor here, not IBM/RH employees. That said, I still would really like to see 32-bit application support not dropped. Maybe the build system could be reworked to allow for selective package building on i686

[ngompa (Neal Gompa)]

@dogphilosopher

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

This also would break OBS’ gamecapture of games since that requires a 32-bit userspace graphics stack.

[ngompa (Neal Gompa)]

@decathorpe

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.

What? Where was that indicated? We have the infrastructure for this with the ELN stuff, a selection of packages could be autorebuilt for i686 in a secondary tag and then the result is merged into composes.

[dhbirb (Dishonest Birb)]

This is a wonderful way to kill off gaming on Fedora, not to mention murdering the usability of projects intended for gaming based off of Fedora (such as Bazzite). Steam itself is 32bit by default still. Flatpak Steam is broken as heck for a lot of use cases, and not really an option. Valve is not likely to change the default 32bit-ness of Steam because Fedora drops i686 support, and even if they did, plenty of games on Steam (especially older titles played on Handhelds a lot) are 32bit.

While Fedora’s focus is certainly not gaming, making the entire distro untenable to anyone who does care about gaming and playing older titles isn’t a great thing. A VM for 32bit games isn’t really a practical solution to this as it’d be an extra hurdle that’d only be happening on Fedora, and it’s doubtful that even if a user were running 64bit Steam that the Steam client would in any way indicate a game was 32bit and so wouldn’t run like it does for macOS. So Fedora would just rapidly get a reputation as “That distro that games don’t work on”, regardless of how accurate or not that may be.

[dmtaylor (Dylan M Taylor)]

If this is the case, I’d love to see us just build the 32-bit packages needed in order for gaming to work correctly. Out of all of the many thousands of packages in Fedora, only a handful are actually neeeded for the gaming use case. As a sample, this is what that looks like on my machine.

# rpm -qa | grep i686
mesa-filesystem-25.1.4-1.fc42.i686
libgcc-15.1.1-2.fc42.i686
llvm-filesystem-20.1.6-1.fc42.i686
mesa-va-drivers-25.1.4-1.fc42.i686
glibc-gconv-extra-2.41-6.fc42.i686
glibc-2.41-6.fc42.i686
expat-2.7.1-1.fc42.i686
zlib-ng-compat-2.2.4-3.fc42.i686
libX11-xcb-1.8.11-1.fc42.i686
libzstd-1.5.7-1.fc42.i686
libstdc++-15.1.1-2.fc42.i686
libffi-3.4.6-5.fc42.i686
libwayland-client-1.23.1-1.fc42.i686
libwayland-server-1.23.1-1.fc42.i686
spirv-tools-libs-2025.2-2.fc42.i686
elfutils-libelf-0.193-2.fc42.i686
libxshmfence-1.3.2-6.fc42.i686
libglvnd-1.7.0-7.fc42.i686
lm_sensors-libs-3.6.0-22.fc42.i686
libXau-1.0.12-2.fc42.i686
libxcb-1.17.0-5.fc42.i686
libX11-1.8.11-1.fc42.i686
libXext-1.3.6-3.fc42.i686
libXxf86vm-1.1.6-2.fc42.i686
libpciaccess-0.16-15.fc42.i686
libdrm-2.4.125-1.fc42.i686
ncurses-libs-6.5-5.20250125.fc42.i686
libedit-3.1-55.20250104cvs.fc42.i686
vulkan-loader-1.4.313.0-1.fc42.i686
xz-libs-5.8.1-2.fc42.i686
libxml2-2.12.10-1.fc42.i686
llvm-libs-20.1.6-1.fc42.i686
mesa-libgbm-25.1.4-1.fc42.i686
mesa-dri-drivers-25.1.4-1.fc42.i686
libglvnd-glx-1.7.0-7.fc42.i686
mesa-libGL-25.1.4-1.fc42.i686
libglvnd-egl-1.7.0-7.fc42.i686
mesa-libEGL-25.1.4-1.fc42.i686
mesa-vulkan-drivers-25.1.4-1.fc42.i686
libnvidia-gpucomp-575.64-1.fc42.i686
egl-x11-1.0.2-1.fc42.i686
egl-wayland-1.1.19-3.fc42.i686
egl-gbm-1.1.2.1-1.fc42.i686
libnvidia-ml-575.64-1.fc42.i686
libvdpau-1.5-9.fc42.i686
libglvnd-opengl-1.7.0-7.fc42.i686
libglvnd-gles-1.7.0-7.fc42.i686
nvidia-driver-libs-575.64-1.fc42.i686
nvidia-driver-cuda-libs-575.64-1.fc42.i686

If we just build those and maybe a few other packages, the maintenance burden would be much lower for packagers and users who want to game on their systems would be happy.

[svin24 (svin)]

I don’t know the specific technical requirements but is it at all possible to only remove packages that are not required the things people still use i686 for?(Steam)

As much as I would like to switch to the flatpak there are many issues with that and it’s not officially supported(as much as I would like for it to be) and there are flatpak specific bugs last i checked.

[decathorpe (Fabio Valentini)]

The problem with this approach is that dependencies change over time. If any package in this “limited set” grows a new dependency that’s not in this set yet, that additional package (and all its transitive dependencies!) need to get pulled into the i686 set too. That sounds like a maintenance nightmare to me, and not a good way to spend package maintainers’ time …

[decathorpe (Fabio Valentini)]

Last I checked, the RPM package for Steam was not officially supported either, or is it?

[rahlquist (Richard Ahlquist)]

I mean honestly, that is the best answer here. Those who strenuously object become contributors and/or built a fork that continues to maintain what they find important, while the core moves on.

[dogphilosopher (Noel Miller)]

The Flatpak is not officially supported either and your proposed alternative is to use that instead of the i686 packages.

As a strong supporter of Flatpaks, it would be awesome if Steam was better supported there, but it architecturally can’t work with how gamescope functions.

The “official” method for installing steam is the debian package they provide on the website or using SteamOS on compatible hardware.

If we want gaming to succeed on Fedora, a Steam RPM (and it’s supporting dependencies) is necessary.

[rokejulianlockhart (Mr. Beedell, Roke Julian Lockhart (RJLB))]

@pizzadude

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

@pizzadude, I also despise using Flatpak where there’s a native package, but is that necessary? For instance, does distrobox work? I realise that it’s technically a container, but it’s as much so as WinSxS is: I’ve found it fairly transparent during my very quick trial of Kinoite.

@dogphilosopher

The “official” method for installing steam is the debian package they provide on the website or using SteamOS on compatible hardware.

@dogphilosopher, so we should be using the .deb on a Debian distrobox image, for the most Fedora and Steam-supported method available?

[smooge (Stephen J Smoogen)]

@ngompa

@decathorpe

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.

What? Where was that indicated? We have the infrastructure for this with the ELN stuff, a selection of packages could be autorebuilt for i686 in a secondary tag and then the result is merged into composes.

I think the main conflicting point isn’t the build system as much as the politics of package maintainership. Fedora does not currently have a good way to separate out ownership per release which means that the main maintainer of a package is the one who gets pinged on every problem for every release and there is no strong way to assign ownership of say the i686 problems to a particular volunteer who says they will maintain i686 glibc or expat or..

It works in ELN for several reasons:

1. Maintainers for the most part don’t have to care about ELN bugs
2. ELN is not a release blocking item. ELN could be broken for days, weeks or months outside of key internal Red Hat dates.
3. ELN i686 support was only important when RHEL had i686 support. The work to keep those builds going was reliant on hacks and work by paid people.

[svin24 (svin)]

It’s not(again I wish the flatpak was official) but I think valve devs would be a lot happier if they had to deal with a non containerized weird install of their program.

I don’t have an issue with removing as many x86_32 packages as possible but I think we should at least keep the steam ones for now.

[dogphilosopher (Noel Miller)]

You can use steam in a distrobox, but this doesn’t solve the problem that downstreams like Bazzite will have.

[rokejulianlockhart (Mr. Beedell, Roke Julian Lockhart (RJLB))]

@dogphilosopher, why? Do they package it in their repositories, rather than RPMFusion?

[scorpio (Eduardo Dias)]

I think this change will do far more harm than good specially with gaming and older software.

In regards to steam another issue with flatpack is that using VR with it it’s simply not possible.

This to me reads like changing for sake of changing and no real progress is being made

[catanzaro (Michael Catanzaro)]

We cannot allow proprietary software that we cannot fix to hold back Fedora development. Removing i686 support is critical. It’s long past time to do this. Thank you, Fabio!

It’s not clear that there is any actual serious problem here anyway. The strongest argument I see above is “I don’t like Flatpak and now I have to install Steam via Flatpak rather than via RPM like I would prefer” which is just not a very convincing use case.

@scorpio

In regards to steam another issue with flatpack is that using VR with it it’s simply not possible.

Surely this is not important enough to merit continued production of i686 packages.

@dmtaylor

If this is the case, I’d love to see us just build the 32-bit packages needed in order for gaming to work correctly. Out of all of the many thousands of packages in Fedora, only a handful are actually neeeded for the gaming use case. As a sample, this is what that looks like on my machine.

That list contains 49 packages. I agree that’s much better than building all of Fedora for i686, but I also highly doubt there’s any valid technical reason for why these libraries should be provided by Fedora rather than let them be provided by Steam itself, or by a third-party RPM repository if Steam does not wish to do so.