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

Reply via email to