On Tue, Jul 21, 2026 at 11:43 AM Daniel P. Berrangé <[email protected]> wrote: > > On Tue, Jul 21, 2026 at 11:24:43AM +0200, Michal Schorm wrote: > > On Mon, Jul 20, 2026 at 4:39 PM Richard W.M. Jones <[email protected]> > > wrote: > > > An i686 build found a 32 bit assumption in my code last week. This > > > happens from time to time and I think it's still useful. So even > > > though I don't think any of my packages are relevant on i686, for me > > > it's worth keeping (some of) them alive. > > > > I see the same sentiment in the s390x discussions, and I'm simply not > > convinced it's worth doing just for the sake of doing it. > > But that's better left for an entirely different mail thread. > > At least in the s390x case, the architecture is still actively being > used and new machines sold. It may not be so compelling to Fedora as > to enterprise distros, but s390x portability is still relevant in > general to projects. The same can't be said for i686. Portability > to 32-bit is largely an academic concern, especially as upstreams > increasingly drop 32-bit support. > > > > Having said that I obviously have no objection if a packger wishes to > > > drop i686 builds from their own package. > > > > I can imagine having a single list of "package: maintainer [, > > maintainer, ...]" format that keeps track of packages and packagers > > who want to keep it building for i686 for any reason, and "steam: > > FESCo" could be the first entry. > > The list, and its dependencies would then be protected against i686 > > removal; at least from this particular effort. > > Trying to allow-list further packages per individual maintainer > desires is undesirable as you can't do that in isolation. It would > have a ripple effect on all dependencies, which would put a burden > on other maintainers. > > If we're to make significant progress eliminating i686, IMHO we > need a use-case focused approach to package inclusion. > > Produce a transitive list of RPMs needed for Steam (and other agreed > important 32-bit end user solutions, if any), then propose to drop > everything else.
This has been discussed previously, and it likely just won't work. We would either need changes to koji for this, *or* add ExcludeArch: i686 to 20000 packages. There's also complications around what constitutes a closed, self-hosted set of packages. You need to consider not only dependencies, but also build-dependencies, and transitive build-dependencies. So the size of the closed, self-hosted set of packages you need for i686 to keep working is surprisingly large. Fabio -- _______________________________________________ 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
