On Tue, Jul 21, 2026 at 04:42:22PM +0100, Daniel P. Berrangé wrote: > On Tue, Jul 21, 2026 at 03:51:44PM +0200, Michal Schorm wrote: > > 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. > > Understood. I support your proposal to move us forward in removing > more i686.
Same here. Michal, you have my support! I read the thread, and there are two proposals: - Your proposal to add ExcludeArch to ~3k packages. - The competing idea to make koji exlude i686 builds by default and convert to an opt-in scheme. The second approach might be conceptually nicer, but: - We don't have a mechanism like this, so we'd need to design it, implement in koji, deploy, and then start using it. - This mechanism would need to not introduce any backward-compatible changes in spec files or elsewhere. - It'd create a lot of churn too, since over time we'd want to stop building more packages, so we'd need to first add a big batch and then remove items from the opt-in list. So unless somebody has an easy way to implement opt-in, I think the opt-out approach with ExcludeArch is worth pursing. To make this concrete, I'd propose the following workflow: 1. create a list of packages to be ExcludeArch'ed 2. file a Fedora 46 Change Proposal for this, with the list 3. (wait for the discussion and approval) 4. push the ExcludeArch additions after branching (Tue 2026-08-11), using provenpackager direct-push workflow. (Why Change Proposal: this is how previous tranches was handled in the past, it raises visibility and gives a good reference point for people. Why ProverPackager-push: with 3k+ packages, PRs would be too much of an overhead. The additions to most packages will be a completely trivial one-line change (+ few a lines entry for packages without %autorelease/%autochangelog). Why F46: it seems late for F45. We want to stabilize things and by the time this could be pushed to F45, we'd be at code completion deadlines and this change could create some disruption.) Zbyszek -- _______________________________________________ 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
