Thanks Dominique and everybody for the reminders about architecture-is-* and SALSA_CI_DISABLE_BUILD_PACKAGE_I386, and thanks Simon for the hint about unsupported-architecture <partial-arch>.
I would like to add that 1) I feel a stronger pressure to keep support on i386, 2) in one of my packaging teams we made our own architecture-restricting (build-dependency) package and 3) we also have problem with architecture-independant packages. What is special with i386? --------------------------- From my point of view of maintainer, I feel a stronger pressure to keep i386 support, because 1) it is the only 32-bit architecture tested on Salsa CI, 2) the scope of the i386 architecture is opt-out rather than opt-in. It gives the impression that deliverying as many packages as possible is considered important. (And I am happy to read opinions that agree that many i386 packages are actually not important). Anyway, i386 autopkgtest failures in Sid eventually kick out the package in Testing from all architectures. Among the solutions, there are: - Upstream is keen on supporting i386 and fixes the problem in a new release. - We carry (and maintain, and refresh, …) patches to support i386 or hide the problem by turning off regression tests. - We disable i386 building for this package. All of these outcomes are extra work for the maintainer. And turning off makes me feel dumb; I did not join Debian to making releases happen by turning off tests. The r-pkg-team-core-architecture package ---------------------------------------- I am aware of the "architecture-is-64-bit" and "architecture-is-little-endian" virtual packages provided by <https://packages.debian.org/architecture-properties>, and I am very grateful that they exist. We use them in the Debian Med packaging team and have used them in the R Packages team. On the other hand, I was not aware of the Build-Depends: unsupported-architecture [i386] trick. In the R Packages team. we started recently to transition to the <https://packages.debian.org/sid/r-pkg-team-core-architecture> empty (but real) package, which will allow us to add or remove a suported architecture to our fixed list with a single upload, and to ensure that new release architectures are not automatically added. Limitations of the current tricks to restrict build architectures ----------------------------------------------------------------- Unfortunately these workarounds do not solve the problem of needing recursive removal of binary packages when removing architectures. Also Salsa CI does not stop testing i386 packages even if the source package is designed to not build them. In addition, virtual or meta build-dependencies also do not solve the problem of architecture-independent packages depending on architecture-restricted packages in their autopkgtest control files, and failing them for that reason. This is why we also make architecture-independent binary packages depend on r-pkg-team-core-architecture, so that the autopkgtests can not even start. This said, I think that illustrates the point that we are reaching the limit of what can be done with workarounds. Perspectives ------------ With team-specific architecture-restriction metapackages like r-pkg-team-core-architecture, teams can focus their time on maintaining a curated subset of Debian release architectures. However, we lose valuable data indicating when or how a dropped architecture might become viable again. Specifically, we lose visibility into build and test failures, which are crucial for reporting issues upstream or summarizing them using an LLM. While this data can be gathered manually, it would be far better to have a proper mechanism that builds and tests everything in Unstable, while allowing teams to filter what actually migrates to Testing. Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://fediscience.org/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
