Fedora 37 Looks To Stop Building Unused i686 Packages

[evil_core]

Yes, the current solution fits better the current situation. But how long will Linux support 32bit apps? On x86, I expect still for many years (only recently Intel removed 16bit support). The bigger problem on x86 will be the package maintance (Linux regularly removes unmaintained stuff, even when people could still use it). And then we have ARM (and laaateeer RISC-V) coming to PC, which don't have 32bit support anymore...

Linux doesn't have stable kernel ABI (or even API), but it's position on non-breaking user-space is very strong, well known and has been well versed on multiple occasions by Linus itself (if you know how devices renaming forth and back is needed by udev and why, then you would know how they takes it seriously ;-)

[ssokolow]

There's no reason for that in WINE, especially to move those libs there and make some shenanigans to not rely on linux 32bit support - it would not only slow down things, but also complicate everything, increasing maintenance burden on WINE side.

I suspect they're referring to how Wine needs to at least do some kind of paravirtualization for 32-bit stuff on 64-bit macOS because Apple reworked the kernel to break it. (If my vague memory is correct, a syscall on the 64-bit macOS kernel on Intel clobbers at least one CPU register that Windows applications expect to be preserved.)

[Ladis]

I suspect they're referring to how Wine needs to at least do some kind of paravirtualization for 32-bit stuff on 64-bit macOS because Apple reworked the kernel to break it. (If my vague memory is correct, a syscall on the 64-bit macOS kernel on Intel clobbers at least one CPU register that Windows applications expect to be preserved.)

Actually, Apple didn't break it. Their (x86) kernel is still able to run 32bit code - just turn it on using a shell command, copy 32bit libs from the previous OS version and reboot:
Easily (Re)enable 32-bit Support in macOS Catalina

This is the future waiting for Linux. Expert more and more 32bit libs to be removed because nobody will maintain them. It already started - many distributions can't run 32bit Linux software anymore, they keep subset of 32bit libs only for WINE to run 32bit Windows software. Some day, even the 32bit support in kernel will be removed, thanks to WINE reworking its libs so the 32<-->64bit conversion is handled locally in WINE (you'll still be able to enable it in kernel and recompile it if you need for other purposes).

The reason CrossOver (commercial version of WINE) does the system libs' calls translation is because it doesn't want to depend on the user to mangle their system for 32bit support. Thus it translates pointers 32<-->64bit and calls the 64bit system libs (the same like WINE and 32bit Windows does to run 16bit apps). At least, even with the standard settings, macOS allows you to run 32bit instructions on the CPU (thus only calls to system libs need to be handled). Also with ARM architeture in M1, there's no 32bit support in the kernel anymore (newer ARM cores don't physically even have it). Thanks to their decision, CrossOver works even on M1 - the 32bit x86 instructions are handled by Rosetta 2 emulation and calling 64bit system libs is handled by CrossOver's pointer translating.

[evil_core]

Actually, Apple didn't break it. Their (x86) kernel is still able to run 32bit code - just turn it on using a shell command, copy 32bit libs from the previous OS version and reboot:
Easily (Re)enable 32-bit Support in macOS Catalina

This is the future waiting for Linux. Expert more and more 32bit libs to be removed because nobody will maintain them. It already started - many distributions can't run 32bit Linux software anymore, they keep subset of 32bit libs only for WINE to run 32bit Windows software. Some day, even the 32bit support in kernel will be removed, thanks to WINE reworking its libs so the 32<-->64bit conversion is handled locally in WINE (you'll still be able to enable it in kernel and recompile it if you need for other purposes).

The reason CrossOver (commercial version of WINE) does the system libs' calls translation is because it doesn't want to depend on the user to mangle their system for 32bit support. Thus it translates pointers 32<-->64bit and calls the 64bit system libs (the same like WINE and 32bit Windows does to run 16bit apps). At least, even with the standard settings, macOS allows you to run 32bit instructions on the CPU (thus only calls to system libs need to be handled). Also with ARM architeture in M1, there's no 32bit support in the kernel anymore (newer ARM cores don't physically even have it). Thanks to their decision, CrossOver works even on M1 - the 32bit x86 instructions are handled by Rosetta 2 emulation and calling 64bit system libs is handled by CrossOver's pointer translating.

https://wiki.winehq.org/FAQ

A few things to note:

• 32 bit Wine runs on both 32-bit and 64-bit Linux/Unix installations. 16-bit and 32-bit Windows applications will run on it.
• 64-bit Wine runs only on 64 bit installations, and so far has only been extensively tested on Linux. It requires the installation of 32 bit libraries in order to run 32 bit Windows applications. Both 32-bit and 64-bit Windows applications (should) work with it; however, there are still many bugs.

1. Current Wine includes support for 64 bit Wine on Mac OS X; however, this has not been tested very much, and some applications may never work due to an ABI incompatibility between Win64 and OS X.

https://www.winehq.org/wwn/364#Wine64%20on%20Mac%20OS%20X

Stefan gave a good explanation:

OSX has an ABI incompatibility with Win64 - OSX overwrites a CPU register that Win64 applications expect to remain untouched. Apple can’t change the ABI because there are already 64 bit OSX apps that expect things to work that way. A potential workaround may be to run Wine inside a CPU emulator like qemu, but that is anything but easy.

So all this shenaningans you've described exists only on OSX and only because it's so broken and cannot be fixed otherwise.

You are are entering territory with more bugs, lesser compatibility, lesser performance and lack of 16bit support.
Exactly what Ms Windows has done, so now Linux + WINE is compatible with greater set of windows native apps, than windows itself (isn't that irony?) and even some people run WINE on Windows (especially in retrocomputing). Less popular than full VMs, but still it says something.

[GI_Jack]

i686 support should be dropped from mainline linux distros.

If there is to be a 32-bit Intel port on modern distros, it should be march pentium4. At this point, this is going to be the oldest still somewhat usable intel hardware. You also drag in SSE2 support so media support isn't too terrible. That is relevant.

Exception is if you are a lightweight, embedded, or aimed at retro-computing distro.

[evil_core]

i686 support should be dropped from mainline linux distros.

If there is to be a 32-bit Intel port on modern distros, it should be march pentium4. At this point, this is going to be the oldest still somewhat usable intel hardware. You also drag in SSE2 support so media support isn't too terrible. That is relevant.

Exception is if you are a lightweight, embedded, or aimed at retro-computing distro.

It's not about 32bit distro for 32bit CPUs, but about few 32bit libs(installed alongside 64bit counterparts in /usr/lib32/ or /usr/lib/, depending on distro).
They can be(and usually are optimized for same CPU as 64bit counterparts and doesn't run on purely 32bit CPU).
Google for Multilib

They are needed for 32bit apps(including 32bit wine, that's needed for 32/16bit windows apps. 32bit DOSemu and DOSBox got also better compatiblity)