Dear colleagues and users,
I would like to propose a change to the Debian-Med team policy:
https://med-team.pages.debian.net/policy/
Given that:
1. The package maintainers in the Debian-Med community are volunteers, and all
of us have many other demands of our time
2. Debian-Med is targeting the use cases of "medical practice and research".
3. Medical institutions and researchers are almost entirely running on amd64
and arm64 systems.
4. The upstream maintainers of the tools and libraries packaged in Debian-Med
are themselves almost entirely volunteers, or if they are maintaining
scientific FOSS projects as part of their work then they have academic jobs.
5. There is no tradition of big-endian computing in the biomedical and life
sciences.
Therefore I personally conclude that:
Support Debian-Med packages for 32-bit and/or big-endian architectures is not a
good use of our limited resources.
(Of course, if the package can only support a subset of the
64-bit+little-endian architectures, that is also acceptable.)
However, I think it is okay if an individual Debian-Med maintainer wishes to
support extra architectures, especially if upstream is supportive. But if that
maintainer can't keep up, and the package is causing problems for other
Debian-Med packages, then we should be okay with removing the extra
architectures again.
If there is agreement with this, then I would like an amend the Debain-Med team
policy to make it clear that we, as a community of package maintainers and
users, are okay with removing support for 32-bit and/or big-endian systems
without discussion.
Like all policy proposals, this is not meant to be a hard rule for all time. We
can and should revisit the issue later!
---
Personal thoughts on Debian's history of bringing up new architectures:
1. This is an aspect of Debian I find to be really impressive! I'm very
grateful for it, and I have seen how other packaging systems struggle when they
have to add a new architecture for the first time.
2. Note that this policy proposal is not "only amd64" or "only amd64 and
arm64". I think supporting new architectures is important to avoid vendor lock-in and provide
portability to the future. For example, I hope to see riscv64 HPC and personal computing become
popular with researchers, software engineers, and (eventually) the public.
3. I still support adding in compatibility for non-amd64/arm64 to scientific
software; especially if SIMD usage is responsible. But I don't think we should
make it a team policy that doing such work is required.
---
How to make implement this policy with the tools available to us in 2024.
New packages that aren't "Architecture: all":
1. Add "architecture-is-64-bit" and "architecture-is-little-endian" to the
"Build-Depends" list in "debian/control".
Removing architectures in existing packages:
1. Check which reverse-dependencies would also need removal (below is adapted
from https://wiki.debian.org/ftpmaster_Removals#Before_requesting_removal )
Debian Developers can run `ssh mirror.ftp-master.debian.org "dak rm
--architecture=armel,armhf,i386 --binary-only --partial --rdep-check --no-action
$SOURCEPACKAGE"`. I don't know of an alternative for non-DDs, sorry.
If any of the reverse-dependencies are not Debian-Med packages (and have
successfully built on the affected architectures) then you must get the
approval of those maintainers before proceeding.
However, that could be a sign that the package should move out from Debian-Med to another team,
like Debian-Science, or something non-research/science related. A good example of this is the zstd
package, first packaged for Debian-Med in 2015 by Kevin Murray; "libzstd1" now has over
2300 reverse-dependencies! The package "graduated" from Debian Med in 2022 and now
maintained by the RPM team
2. Add "architecture-is-64-bit" and "architecture-is-little-endian" to the "Build-Depends" list in
"debian/control" and upload a new version of the package to "UNSTABLE".
3. Repeat #2 for each of the affected Debian-med reverse-dependencies (and
coordinate with any other maintainers as needed)
4. `reportbug ftp.debian.org` to request a "ROM Package removal - Request Of
Maintainer." and list the official architectures to remove the binary packages of: typically
that would be "armel armhf i386 s390x".
5. Repeat #4 for each of the affected Debian-med reverse-dependencies.
Coordinate with the other maintainers to do the same.
6. Help the FTP team by marking which removal bug block which dependency.
7. Wait for the packages to be removed and the new uploads to migrate to
testing, responding to any queries from the FTP team.
Alas this is an involved process. If we have to do it a lot, it would be nice
if someone writes a tool to automate any aspect of the above!
---
Fweh, that's a long email. Please do share your feedback here and on the
Debian-Med Matrix channel for instant discussions:
