On Tue, Jul 21, 2026 at 1:27 PM Fabio Valentini <[email protected]> wrote: > We would either need changes to koji for this, *or* add ExcludeArch: > i686 to 20000 packages.
Only ~10,000 packages *can* produce i686 binary RPMs. Only ~8,500 currently *do* produce them, and my proposal would cut the number in half. I can do the work if that's the problem. It's just one huge bulk operation. Having 'ExcludeArch' in thousands of packages isn't the most elegant solution, but the cost value effectivity specifically for the cut I propose here is IMO great. Especially since it requires zero build system changes and (close to ?) no maintainer disruption. On Tue, Jul 21, 2026 at 11:44 AM Daniel P. Berrangé <[email protected]> wrote: > 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. My personal goal here (which I believe is achievable) is to do a one-time high-value cut of all the easy-to-cut packages. I specifically do not want to dive deeper into the rabbit hole of full i686 removal - I consciously took an easy task (in comparison) so we make any progress at all, and I will leave the hard part of doing the rest to others. While definitely undesirable, if that were the only way to get approval for this cut, I'd create such a list and keep the transitive dependencies of those packages. I'd honor the list for this cut, and again, leave the hard work of figuring out what to do with the list in the future for someone else. I'd sure be happier without the per-packager wish list though. Michal -- Michal Schorm Senior Software Engineer Databases Team Red Hat -- On Tue, Jul 21, 2026 at 1:42 PM Daniel P. Berrangé <[email protected]> wrote: > > On Tue, Jul 21, 2026 at 01:26:08PM +0200, Fabio Valentini wrote: > > 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. > > The stats quoted elsewhere in this thread were not as large as 20k: > > >>> Total source packages in Fedora: 23,245 src.rpm > >>> Produce only noarch (i686 irrelevant): 12,620 src.rpm > >>> Already ExcludeArch i686: 2,431 src.rpm > >>> Currently producing i686 binary RPMs: 8,318 src.rpm / 19,306 bins > >>> > >>> Proposed to remove (koji-only + leaf): 3,401 src.rpm / 3,557 bins > >>> Would remain building i686: 4,917 src.rpm / 15,749 bins > > So i guess what I'm asking is can we use knowledge of what is > used by Steam, to cut that 4917 down even more. > > It was suggested we might invert the behaviour to opt-in to > i686, instead of opt-ing out. If we want an opt-in, then > getting that 4917 figure as small as possible appears pretty > beneficial. > > > 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. > > Yes, we need to recursively chase the deps. > > > So the size of the closed, self-hosted set of packages you need for > > i686 to keep working is surprisingly large. > > Yes, but hopefully still significantly smaller than the 4917 listed > above. > > With regards, > Daniel > -- > |: https://berrange.com ~~ https://hachyderm.io/@berrange :| > |: https://libvirt.org ~~ https://entangle-photo.org :| > |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :| > > -- > _______________________________________________ > 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
