Re: What is the preferred way to ask for large numbers of arch-specific removals?
Am Fri, Dec 19, 2025 at 09:34:39PM +0000 schrieb Bill Allombert:
'architectures are not supported upstream' has never been a criterion to
remove binaries, otherwise we would remove the majority of binary
packages.
Le Sat, Dec 20, 2025 at 05:11:40PM +0100, Andreas Tille a écrit :
That's correct. Maybe Charles was a bit short in giving the reasons for
the removal: Architectures the packages that are not used in practice
since nobody in Science does for instance gene sequencing on some 32bit
hardware and at the same time draining developer time that could be used
for actual user relevant problems might have been the better phrasing.
There are practical reasons why upstream does not support this and we
need to face reality that our person power is not better than upstream.
Thanks Andreas,
indeed, in my message I focused on the "how" and left out the "why".
The r-cran-* r-bioc-* packages are a large set with a lot of
cross-dependencies, but little anchorage to the rest of our packages.
In particular, I have verified that architecture removals will only
impact science packages, and have obtained consensus on the debian-med,
debian-r and debian-science lists. Discussion with the release team
also cleared out the possibility of hitting key packages.
I admit that removal of little-endian architectures is heavy-handed and
I would not be doing it if it would not be easy to do it for free while
removing the 32-bit architectures. If little-endian architecture
porters contact us at the debian-r mailing list with evidence for need,
feasibility and commitment, I am happy to stop depending on
architecture-is-big-endian. In the meantime, I think that it is in
everybody's best interest, given how frequently autpkgtest failures
derail our transitions. By the way, I was really happy to read about
Debusine. Among the wonders it promises, it opens a straigthforward
method to ask "is it time to distribute this class of packages on this
architecture"?
I would like conclude by stressing out that I am not proposing to
restrict the builds to only the architectures supported upstream.
Upstream only supports Linux/amd64. It also supports MacOS/AppleM but
there are diffences with Debian/arm64 such as extra precision and signed
characters. Yet, the changes I am working on keep automatic building on
arm64, loong64, ppc64el and riscv64.
Have a nice week-end!
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
Reply to: