On Sat, Jul 18, 2026 at 3:21 AM Mateus R. Costa
<[email protected]> wrote:
>
> Em sex., 17 de jul. de 2026 às 22:03, Michal Schorm
> <[email protected]> escreveu:
> >
> > On Sat, Jul 18, 2026 at 2:32 AM Mateus R. Costa
> > <[email protected]> wrote:
> > > This brings it to my question: since to me I am almost sure nobody will 
> > > ever install the x86_32 version, although it's perfectly buildable, what 
> > > prevents me from, as a packager, to simply disable it for only that 
> > > package?
> > >
> > > Is there a specific policy I should be aware of?
> >
> > Hi Mateus,
> > The current policy actually encourages package maintainers to drop the
> > leaf i686 packages on their discretion:
> >   https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval
> > You can go for it right now.
>
> You linked me to a Change, and specifically a Fedora 37 one.
> When I learned packaging RPMs I don't specifically remember whatever
> tutorial I read (which was probably on Fedora Docs) nor other RPM
> documentation on Fedora Docs I don't really remember anything pushing
> dropping x86_32 support.

Fedora i686: Quick Summary Timeline:

* F27 (2017) — First proposal to drop i686 kernels. Deferred by FESCo.
https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels

* F31 (2019) — i686 kernels + standalone repos dropped. Multilib and
Koji builds kept.
https://fedoraproject.org/wiki/Changes/Noi686Repositories

* F37 (2022) — Leaf packages can add 'ExcludeArch: %{ix86}' freely.
~230 source packages baselined as "should stay."
https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval

* F44 (2025-06-24) — Comprehensive proposal to drop all i686 (multilib
+ Koji builds). ~400 comments, withdrawn 4 days later.
https://discussion.fedoraproject.org/t/f44-change-proposal-drop-i686-support-system-wide/156324

* F44 (2025) — Narrow QEMU i686 drop accepted separately.
https://fedoraproject.org/wiki/Changes/DropQEMU32bitHostBuilds

Current state: multilib active, Koji i686 builds active, no FESCo
policy on long-term direction. Gaming (Steam/Wine) is the dominant
reason i686 stays. Wine WoW64 readiness unclear.

Key threads:

2022 FESCo survey (60+ replies):
https://lists.fedoraproject.org/archives/list/[email protected]/thread/TWTVN6FS745O5ZIWRT4SJIBS5S4C4BKL/

i686 problem statement:
https://discussion.fedoraproject.org/t/i686-in-fedora-problem-statement/157062

mock i686 cross-build (open since 2019):
https://github.com/rpm-software-management/mock/issues/340

--

Michal Schorm
Senior Software Engineer
Databases Team
Red Hat

--

On Sat, Jul 18, 2026 at 3:21 AM Mateus R. Costa
<[email protected]> wrote:
>
> Em sex., 17 de jul. de 2026 às 22:03, Michal Schorm
> <[email protected]> escreveu:
> >
> > On Sat, Jul 18, 2026 at 2:32 AM Mateus R. Costa
> > <[email protected]> wrote:
> > > This brings it to my question: since to me I am almost sure nobody will 
> > > ever install the x86_32 version, although it's perfectly buildable, what 
> > > prevents me from, as a packager, to simply disable it for only that 
> > > package?
> > >
> > > Is there a specific policy I should be aware of?
> >
> > Hi Mateus,
> > The current policy actually encourages package maintainers to drop the
> > leaf i686 packages on their discretion:
> >   https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval
> > You can go for it right now.
>
> You linked me to a Change, and specifically a Fedora 37 one.
> When I learned packaging RPMs I don't specifically remember whatever
> tutorial I read (which was probably on Fedora Docs) nor other RPM
> documentation on Fedora Docs I don't really remember anything pushing
> dropping x86_32 support.
>
> So unless something was added between then and now, or that I simply
> missed it, then potentially having the info to drop x86_32 if feasible
> on newer packages intended to the Fedora repos probably is a good
> idea.
> This is mostly in the "let's not keep accumulating new packages".
> Probably also interesting to bring up in package reviews for newer
> packages or unretired ones.
>
> > This thread's goal is to coordinate a larger independent effort - here
> > I seek validation of my analysis, and assistance with realization.
>
> I'm all for it, I am in favor of removing most 32-bits stuff except
> for the most likely libs to be needed if I ever have to manually run
> some 32-bit binary (which probably the FESCo list already covers).
> Though today most usecases where I would need to actually do that I
> probably can use flatpak or distrobox (even if in a non-Fedora
> container).
>
> So, I will handle bign-handheld-thumbnailer later. Though I will have
> to check how well that ExcludeArch policy is advertised on the
> packaging docs...
>
> Thanks for your time,
> Mateus Rodrigues Costa
>
> > --
> >
> > Michal Schorm
> > Senior Software Engineer
> > Databases Team
> > Red Hat
> >
> > --
> >
> > On Sat, Jul 18, 2026 at 2:32 AM Mateus R. Costa
> > <[email protected]> wrote:
> > >
> > >
> > >
> > > Em sex., 17 de jul. de 2026, 19:32, Michal Schorm <[email protected]> 
> > > escreveu:
> > >>
> > >> For those interested in this topic, I compiled a set of packages that 
> > >> exactly:
> > >>   builds i686 && all binary RPMs are buildroot-only && leaf && NOT on
> > >> FESCo "protected" list
> > >>
> > >> https://mschorm.fedorapeople.org/ARCHIVE/i686-removal/koji-only-leaf-i686_2026-07-18.txt
> > >>
> > >> If my method and understanding are both correct, we could add
> > >> 'ExcludeArch: %{ix86}' to each of these 3,400 packages with zero
> > >> impact on the rest of the packages and save some resources.
> > >>
> > >> What do you think?
> > >
> > >
> > > I noticed bign-handheld-thumbnailer made it to this list.
> > >
> > > Since that project is just a thumbnailer and preferably the version 
> > > equivalent to the host os architecture should be installed (and there's 
> > > no x86 32-bits Fedora anymore AFAIK), this makes me curious on something.
> > >
> > > It seems to me that you're saying "hey, we could remove 32-bits x86 
> > > versions from these!", as if a large portion of the community has to 
> > > agree beforehand on whether it's a good choice.
> > >
> > > This brings it to my question: since to me I am almost sure nobody will 
> > > ever install the x86_32 version, although it's perfectly buildable, what 
> > > prevents me from, as a packager, to simply disable it for only that 
> > > package?
> > >
> > > Is there a specific policy I should be aware of?
> > >
> > > Thanks for your time,
> > > Mateus Rodrigues Costa
> > >
> > >>
> > >>
> > >>
> > >> Michal
> > >>
> > >> --
> > >>
> > >> Michal Schorm
> > >> Senior Software Engineer
> > >> Databases Team
> > >> Red Hat
> > >>
> > >> --
> > >>
> > >> --
> > >> _______________________________________________
> > >> devel mailing list -- [email protected]
> > >> To unsubscribe send an email to [email protected]
> > >> 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/[email protected]
> > >> Do not reply to spam, report it: 
> > >> https://forge.fedoraproject.org/infra/tickets/issues/new
> > >
> > > --
> > > _______________________________________________
> > > devel mailing list -- [email protected]
> > > To unsubscribe send an email to [email protected]
> > > 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/[email protected]
> > > Do not reply to spam, report it: 
> > > https://forge.fedoraproject.org/infra/tickets/issues/new
> >
> > --
> > _______________________________________________
> > devel mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
> > 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/[email protected]
> > Do not reply to spam, report it: 
> > https://forge.fedoraproject.org/infra/tickets/issues/new
> --
> _______________________________________________
> devel mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> 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/[email protected]
> Do not reply to spam, report it: 
> https://forge.fedoraproject.org/infra/tickets/issues/new

-- 
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it: 
https://forge.fedoraproject.org/infra/tickets/issues/new

Reply via email to