TL;DR: bitrotting, crumbling, extra work, help Hi Holger and everybody,
The reason I am unhappy about the way i386 is managed is that I am part of a packaging team that maintains more than 500 architecture-dependent packages, and I see that upstreams compatibility with i386 (and all 32-bit arches, to be honest) is in the process of bitrotting. Many packages have reverse-dependencies only within the team. The need for support removal pops up randomly, it is out of my control and very disempowering. The package names starts with r-cran. Upstream, they are tested against amd64 and Silicon only. If you look at the health of the packages and the team, it is not good. Well it is as good as many pieces of the free software ecocystem: crumbling under the weight. Let's look at the options for i386: - Remove it from released architectures. Treat is like other non-release ports: Architecture: any builds them, but build failures or CI regressions are not release-critical. - Keep some packages to be installed as multi-arch or chroot, opt-in. This is extra work for the maintainers of packages opting in. - Same but opt-out. This is extra work for opting out. In my opinion, the opt-out option is the one that burns the most man-hours, mostly of unpaid volunteers. I wonder if it was underappreciated when chosing this way. Is there a way to get assistance to manage the progressive loss of i386 compatibility upstream, in a way that will consume less time than changing 500 packages and filling 500 removal bugs by hand? Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from home https://framapiaf.org/@charles_plessy - You do not have my permission to use this email to train an AI -
