F44 Change Proposal: Drop i686 support (system wide)

Project Discussion Change Proposals
,
244

I was describing the capabilities we currently have. There are lots of proposals for new approaches in this thread, and some of them may be great ones, but none of them currently exists. I try not to worry about things that don’t exist yet.

I was replying to a post that I read as suggesting we could ‘just’ build fewer i686 packages under the current system, and that would solve all the problems. I was explaining that IMHO it does not, really. Shiny ideas for different ways to skin the cat were a bit out of scope.

If someone were to take one of the (possibly great) ideas from this thread and turn it into an actual Change proposal pitched as an alternative to this one, thus saying that they intend to actually do that idea, then I’d start thinking about it.

1 Like
245

What are your thoughts on the proposal here?

Obviously it needs to be drafted up and presented to have a more clear set of criteria, but I think having the opportunity to prove out more ideas for such an impactful change is a good idea. Then it is a win-win for everyone!

246

Blind development is (almost inarguably) always bad.

“You” can create something beautiful but that no one will actually want.

.

There’s a reason why Android is the most popular “version of Linux”, used by most people ever:
It’s an Operating System which both just works and does what the End User wants it to do.

{Here is the best section to say this:}

Dropping 32bit support, RIGHT NOW, honestly just feels like change for the sake of changing things.

.

The most similar thing to dropping 32bit instructions which recently happened is Nvidia dropping PhysX support on their cards, and even this isn’t close to what is being proposed here.

I am NOT an expert about this, I am not even very well informed, and I will not pretend to be, but even if we ignore/take_as_a_given that “devs will just update their stuff to work in 64bits” or “downloadable stuff can be made” this will still give some compatibility problems to software which is not even that old.

I am not talking about the Intel 486 or even Pentium 3s, THAT hardware is BOTH rare AND weak. Support for it by large groups has already (largely) been dropped and those who are interested into using them, for any reason, either find way to run custom Linux installs themselves, have small groups develop compatible Distros, or just run Windows 98.

I am talking about systems which,

altho weaker (because they range from the Pentium 4 to the 2014 CPUs), they are still capable of running modern Operating Systems and maybe even be performant enough to be daily-use-machines since almost all of them have the same instruction sets which NEW CPUs releasing to this day still have.

This situation is similar to the reason why ARM CPUs were born:
People didn’t care for a god-chip which could run 30 billion divisions in a nanosecond, because it’d cost 30 billion kidneys AND they didn’t need/care_for it.
ARM CPUs had a more limited set of instructions which those users actually needed and thus answered a demand by creating a new section of the market.

What would cutting 32bit support RIGHT NOW achieve?

.

AGAIN, I know very little about this (and honestly I use my computer for Web Browsing, gaming, and content creation), so I don’t know what would be lost and how it may be “recovered by independent devs” if Fedora drops 32bit support,
but both on the hardware side of this issue, and on the larger software side, most Devs and End Users still have something to do with 32bits, so a change this soon would hurt Fedora more than it could ever benefit it.

.

Altho Linux, as an overall body, basically runs the “Servers side” of the computer world, it is hardly even noticeable on the End User side.

The “End User side of Linux” can not be “a market leader, moving the world of its dominion towards its vision”, even less Fedora itself, because of its minuscule size and thus impact.
Valve managed to make Microsoft drop their Windows 8 ideas by actually threatening Microsoft’s earnings, and altho Windows 10 came,
Valve’s ambition for autonomy, to not be under Microsoft’s thumb, is what HEAVILY helped Linux to even just be desirable for those Users which have interest in how their PCs work.

THE ABSOLUTE VAST MAJORITY of End Users don’t even want to know how their magic box works, as it should be, and as it will always be.

Money is paid, product which works is taken.
Most don’t have much free time, and almost all don’t want to spend it learning what they don’t care about. An OS which can operate through a GUI alone is what all want for their “I am here to not work” computers.

All my PCs now have Fedora KDE, and the livingroom one is used by the entire family. When something breaks I am the one dealing with it because I like it, it is MY interest, MY passion; if I wasn’t like this my household would already be filled with Windows 11 machines.

.

AGAIN, I am NOT an expert, but even I know that “cutting 32bit support is not a small thing”.

Development of a product (which Fedora is) can be done in just 2 ways:
Either the ones whom develop it see and thus respond to the demand around them, or create something which may or may not spark a different demand in the future.

I honestly believe that focusing on “64bit support only” for Fedora, small Fedora, would create a product which has no demand by really anyone.

I have already made a long enough message, and making it longer wouldn’t add anything important, so I am gonna close this one here.

.

I have no ill intent, I don’t care about attacking anyone personally, I am just discussing ideas.
I can absolutely be wrong on things, it’s human, but I am still talking about things in the most objective way possible, trying to compensate for my human biases.

I only care about an Operating System which is does what I want, and if more complex actions are needed for more complex operations, so be it, as long as the instructions are easily_found/given, clear to understand and they don’t “randomly not work for no good reason at all”.
I hope Fedora can get closer to that goal.

1 Like
247

What I had been assuming we’d do is: ship normal x86_64 packages that just happen to contain i686 code instead of x86_64 code, and make sure they contain only the library .so to not conflict with the normal x86_64 package. Unlike our mingw packages, the i686 package would need to be a subpackage of the normal package, because that will allow us to keep the i686 package in sync with the main package.

Although, as I reconsider this, I wonder if perhaps all that is just a worse version of the multilib support that RPM already has.

(Note the packages wouldn’t actually need to be cross-compiled, since -m32 would work.)

248

Coming in with some results of my conversation with Pierre-Loup Griffais (aka Plagman), who is a software engineer with Valve:

Have some thoughts I’d like to get out into this thread, but will revisit later once I have more time. Initial takeaway is that it seems Valve might have some currently valid concerns with shipping a 64-bit client.

5 Likes
249

I would just like to add my 0.02$. The underlying issue here is resources for maintaining multi-lib. I would argue that from a functionality/utility perspective the ideal scenario is that Fedora should be looking to implement wider multi-lib support rather than reducing it. This is very much in view of how little and how frustrating it is to use a fedora/RHEL base in CI/CD pipelines where a project is targeting i.e x86_64 and aarch64 and how much of the marketshare we have lost out to bespoke buildroot cross compilation containers etc in the last several years due to our historical decision around multi-lib.

It relatively clear IMNSHO that this was a mistake.

Perhaps this proposal needs to be changed to : request funding for resources to expand mulit-lib support in fedora?

250

In fact, many of our mingw packages are now handled that way. The integrated (subpackage) approach is now documented as the preferred approach in the packaging guidelines, Packaging Guidelines for MinGW Cross Compilers :: Fedora Docs.

See also Planning to start unifying native and mingw packages - devel - Fedora mailing-lists.

3 Likes
251

This is almost exactly the answer I expected, and it’s the answer I would have given if I were in Valve’s position.

1 Like
252

A 64-bit client could still launch 32 bit games unless the 32-bit libraries were dropped.

253

I think the simple answer is valve is not going to change just because fedora wants change. If that bluesky post is to be true they have a financial reason to not change how they are doing things. Unlike apple fedora cant pass some cash under the table. Not saying that happened.

254

Can it not be done in phases?
Phase one: No new 32 bit programs in repos and open a 64 bit only test branch to identify more pain points.
Phase two: Create a support group to help get 32 bit programs modernised and removing those pain points.
Phase three: Start culling unused packages/libraries.
Phase four: Maybe make 32 bit compatibility opt-in in the installer, and point people toward the aforementioned support group if/when they encounter issues.
Phase five: The eventual removal of official 32 bit support.

Personally I think with the long legacy of 32 bit computing this timeline should be as long and drawn out as feasible but it does have to happen eventually and the sooner it’s started the longer people have to get things sorted out.

Personally, Steam is a dealbreaker for me, as is recording stuff in OBS. I wouldn’t be surprised if there are other 32 bit things I’m dependant on without knowing. I like my experience with Fedora so far, while I know that 64 bit Steam is beyond Fedora’s scope to fix, I’d hate to be forced to another distro on account of this.

3 Likes
I686 in Fedora: problem statement
255

I have a large C application (about 10 million lines of code) that would be too hard to convert to build as 64 bits because it has too many places that know that ints and pointers are 32 bits. Here is the total list from ldd. It needs only a few more libraries not in your list. I could build libraries from source, but especially with libraries like libcrypto and libssl, having Fedora maintain them with security updates would be much safer.
/lib/ld-linux.so.2 (0xf7f6c000)
libLerc.so.4 => /lib/libLerc.so.4 (0xf70fa000)
libX11.so.6 => /lib/libX11.so.6 (0xf7de2000)
libXau.so.6 => /lib/libXau.so.6 (0xf6f80000)
libXft.so.2 => /lib/libXft.so.2 (0xf76ad000)
libXrender.so.1 => /lib/libXrender.so.1 (0xf6fbf000)
libbrotlicommon.so.1 => /lib/libbrotlicommon.so.1 (0xf6974000)
libbrotlidec.so.1 => /lib/libbrotlidec.so.1 (0xf6b29000)
libbz2.so.1 => /lib/libbz2.so.1 (0xf6cb3000)
libc.so.6 => /lib/libc.so.6 (0xf7312000)
libcrypto.so.3 => /lib/libcrypto.so.3 (0xf79da000)
libfontconfig.so.1 => /lib/libfontconfig.so.1 (0xf7099000)
libfreetype.so.6 => /lib/libfreetype.so.6 (0xf6fcd000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf6cc8000)
libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0xf69b7000)
libgraphite2.so.3 => /lib/libgraphite2.so.3 (0xf6998000)
libharfbuzz.so.0 => /lib/libharfbuzz.so.0 (0xf6b38000)
libjbig.so.2.1 => /lib/libjbig.so.2.1 (0xf70ec000)
libjpeg.so.62 => /lib/libjpeg.so.62 (0xf775c000)
liblzma.so.5 => /lib/liblzma.so.5 (0xf6f85000)
libm.so.6 => /lib/libm.so.6 (0xf7810000)
libpcre2-8.so.0 => /lib/libpcre2-8.so.0 (0xf68c8000)
libpng16.so.16 => /lib/libpng16.so.16 (0xf6c73000)
libsharpyuv.so.0 => /lib/libsharpyuv.so.0 (0xf6f76000)
libssl.so.3 => /lib/libssl.so.3 (0xf78f4000)
libstdc++.so.6 => /lib/libstdc++.so.6 (0xf6cfd000)
libtiff.so.5 => /lib/libtiff.so.5 (0xf76c9000)
libwebp.so.7 => /lib/libwebp.so.7 (0xf7257000)
libxcb.so.1 => /lib/libxcb.so.1 (0xf72e4000)
libxml2.so.2 => /lib/libxml2.so.2 (0xf7536000)
libz.so.1 => /lib/libz.so.1 (0xf750e000)
libzstd.so.1 => /lib/libzstd.so.1 (0xf719b000)
linux-gate.so.1 (0xf7f6a000)

256

Reading through this vital discussion, it’s clear we’re facing a difficult crossroads. On one hand, the maintenance burden of i686 is real and growing, as outlined in the Change Proposal. Upstreams are dropping 32-bit support, and our volunteer packagers are spending increasing effort on a legacy architecture. On the other hand, the concerns raised by the community are equally valid and critical: dropping multi-lib without a robust alternative will break essential use cases for a significant portion of our users, especially around gaming (Steam, native Linux games, Wine), and harm downstream projects like Bazzite that are bringing new users to the Fedora ecosystem.

The current debate seems stuck between two poles: “keep the maintenance burden” or “break user applications.” I believe there is a third way.

The proposal document I’ve been working on, which I’ve tentatively called the Fedora Universal Build Environment (FUBE), is an attempt to define that third way. It’s a full architectural proposal designed specifically to achieve the goals of the Change Proposal (drastically reducing the maintenance burden) while directly addressing the concerns raised here.

The core idea is to replace the old, problematic multi-lib system entirely with a modern, container-based approach that is composable and maintains a pristine 64-bit host.

Here’s how it addresses the key points from this thread:

1. For Users & Gamers: A Clean, Seamless 32-bit Runtime

Instead of installing hundreds of i686 packages on your host system, FUBE provides a single, official, minimal fube-runtime:i686 container. A smart tool (fube-run) would be integrated with the OS so that when you try to run a 32-bit binary (like Steam or a legacy game):

  • It transparently launches the application inside this 32-bit container.
  • It seamlessly “stitches” the graphics, audio, and input back to your desktop. To you, it just looks and feels like a native app.
  • This solves the “just use Flatpak” problem. While Flatpak is a great option, this provides a system-level solution that works for applications outside of Flathub and, crucially, for complex services.

2. For Bazzite & gamescope-session:

The FUBE architecture is explicitly designed to solve the problem described by the Bazzite developers. The fube-run tool can use a “sibling container” model. A 64-bit gamescope session can run in one container and, when it needs to launch the 32-bit Steam client, it can command the host to launch a separate, dedicated 32-bit container for Steam that is seamlessly composited within the main session. This provides the necessary environment without needing Flatpak and without a monolithic, custom-built container image.

3. For Maintainers: A Drastic Reduction in Burden

This model directly addresses the maintenance nightmare.

  • Instead of thousands of i686 packages to maintain, the entire effort is consolidated into maintaining one generic i686 runtime image.
  • This elegantly solves the “cascading dependency” problem. A package adding a new dependency doesn’t break a curated list; the dependency is simply added to the generic runtime image during its next rebuild.
  • This also addresses the infrastructure complexity. The hacks needed to merge i686 packages into the x86_64 repos are no longer needed. The build system becomes cleaner and simpler.

4. For Developers: A Modern Cross-Compilation Story

Beyond just i686, FUBE provides a high-performance cross-compilation toolkit for modern architectures like AArch64. It uses native cross-compilers for speed, ensuring Fedora remains a top-tier development platform.

This proposal is not about “kicking the can down the road.” It is a concrete technical proposal to rip out the old, problematic system and replace it with something better. It allows us to say “yes” to reducing the maintenance burden and “yes” to our users who want their applications to keep working.

I believe this architectural approach offers a viable path that respects the motivations of the original Change Proposal while protecting our users and downstream communities.

Draft project proposal attached. Keen to hear feedback.

12 Likes
257

I am personally against the change as it currently stands, If it breaks gaming then you’re actively taking away one of the only reasons I use my PC. Fedora has been a sanctuary for this where I can get great features early for new hardware without being forced on a bleeding edge distro that causes a lot of breaking changes and I am not forced onto a distro like Ubuntu or Debian which doesn’t adopt fast enough.

It’s been a middle ground that has been perfect for a long time and Bazzite has packaged that all up nicely.

A note: Bazzite has allowed me to extend linux to my daughter, father, niece, and close non-technically inclined friends. The simplicity of “it just works” has allowed Fedora to be a home for those it would of otherwise not been an option. Please do not take this for granted, this has opened my daughter’s eyes to the possibilities of linux and fostering the next generation of FOSS focused people. Going against this and purposely breaking it for the sake of change will be a big blow on my end.

I respect all the work that goes into maintaining this and I do see the need, but it can’t be done with willing knowledge that it will “hurt” the users that contribute to the success of the project.

Thanks!

2 Likes
258

There is a lot of old software that requires 32-bit in one form or another. This includes both Linux native and applications running on Wine, since 32-bit Wine also requires the system to have 32-bit libraries. While it is true that containerization can fix some of this, they also introduce many other issues, such as hardware support (including GPUs). It is for this reason that I object to the discontinuation of 32-bit support. Unfortunately, I do not know how much time is spent maintaining 32-bit packaging.

259

It could be part of the new-package review process to ensure that an ExcludeArch: is in new packages unless the packager states that 32-bit is a requirement. That might prevent the number of 32-bit packages from growing (although I don’t know how much that would help the other identified pain points). I presume this change would need approval from the packaging group.

260

I’m a little late to this thread. However, I echo Neal and Noel on this.

This gives me pause. My wish is to see this not happen.

Gaming is very important to me and to Linux friendly hardware sellers.

5 Likes
261

Greetings, I’d like to share my humble opinion. For many years, Linux has been continuously overlooked on home computers. For the first time, Linux is being talked about widely, and for better or worse, it’s thanks to Steam. That’s why I think it would be a mistake to remove multilib support from Fedora, since Steam would no longer be installable on it. Right now, Linux depends more on Steam than Steam depends on Linux, so I believe this decision should be reconsidered.

4 Likes
262

Will this container be able to launch 64bit programs, though? While Steam itself is 32 bit, many of the games it launches are 64 bit; you mention that the 64bit session can launch the 32 bit Steam client, but would it be as trivial to make it work in the inverse? I imagine it should be the same process; the reaosn I ask is simply because we should be thinking about things.

I’ll also say that there is an entirely separate conversation regarding Compilers going on in the devel mailing list; the GCC maintainers want to still be able to access 32 bit libraries. While this proposed solution solves the gaming issue and other software, would fube work for compilers? What about as a dev environment in general?

EDIT: I do love the name, by the way.

1 Like
263

I want to expand on the aarch64 emulation situation:

  • Fedora aarch64 relies on i686 packages to build support for running i686 binaries under emulation in the context of the host system (without containers). If Fedora x86_64 drops i686 support entirely, that means Fedora aarch64 also won’t be able to run i686 binaries. This sounds trivial on the face of it (why would aarch64 be able to run things x86_64 can’t?), but:
  • The emulation technology we use (FEX) currently does not support integration with containers (other than one-off hacks with pressure-vessel which is what makes Steam work). That means that if the story for Steam/etc users is “use a Flatpack/distrobox/whatever”, aarch64 users have no options left. I have a vague plan to fix this, but it involves a lot of changes to FEX and a kernel patch (and who knows if upstream would even accept it). I wouldn’t count on this being resolved and deployed in the short term. This should be a blocker for dropping i686 support if the story is “use containers”, because otherwise that would be throwing all aarch64 users under the bus and undoing all the work that went into x86_64/i686 emulation.
  • As a much smaller issue, building FEX 32-bit thunks (which happens in x86_64 builders) relies on a tiny set of packages extracted to get 32-bit headers. Currently, the only i686 package that is part of the set is glibc-devel.i686. So at the very least, I hope we can package that (and in general support for compiling 32-bit apps) for x86_64 Fedora, even if we don’t ship any 32-bit versions of libraries beyond the toolchain/glibc.
16 Likes