On Tue, Jun 24, 2025 at 11:02:56AM +0100, Aoife Moloney via devel-announce wrote: > == Detailed Description ==
snip > 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). What kind of "potential issues" are liable to justify reversing the decision to drop i386 ? Assuming we confirm that the Wine change is just a formality at before approving this change, that would address the big blocker in Fedora. What else would be high profile enough *in Fedora* to merit a blocker ? IMHO external apps should not influence our decision, and must adapt to what the distro decides to provide. The QEMU release coming in Dec this year is expected to be dropping all support for building on 32-bit hosts, and the ripple effect on packages across Fedora is non-negligible. We're looking at a choice of updating Exclusive/ExcludeArch across many packages (which I'm dieing to avoid the busy work for), or not doing any further updates of QEMU in rawhide until i686 is turned off in koji which is also undesirable as it delays feature integration & testnig. IOW, from a (somewhat selfish) POV as a maintainer of QEMU, I'd prefer us to go straight to turning off i686 in koji when the F44 dev cycle opens. > === 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. Yep, this. Fedora's policy of only turning off i386 in leaf packages has left us in a painful situation as upstream projects in non-leaf context increasingly decide that 32-bit isn't something they're willing to continue to support. > == Dependencies == > > * wine: build package with "new WoW64" mode enabled > * steam: adapt or drop RPM package from default third-party repositories IMHO whatever happens with steam should not be our concern. If steam happens to work on Fedora that's nice, but IMHO its needs don't align with the Fedora project "four foundations" or mission. Thus it shouldn't have significant influence the decision to drop i386, nor be the kind of thing that would justify a reverse in the change inbetween disabling the compose for i686 and turning off i686 in koji With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- _______________________________________________ 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