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: https://app.element.io/#/room/#debian-med:matrix.org Cheers from Berlin, -- Michael R. Crusoe
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature