Hi all, first of all thanks Michael for this idea and also for the elaborate proposal email that outlines the intended way to go quite well. [...]
Support Debian-Med packages for 32-bit and/or big-endian architectures is not a good use of our limited resources.
Agreed. [...]
However, I think it is okay if an individual Debian-Med maintainer wishes to support extra architectures, especially if upstream is supportive.
Also, agreed. I am very likely not that maintainer. Various times already I have been struck by bug reports and failing builds for release platforms that are probably irrelevant for most users of the affected software. I pushed through to fix the issue while knowing that the typical user would not be using this specific software on, say, s390x or a Raspberry Pi. Yes, I am aware that having all that variety at our fingertips promotes experimentation, but does that really justify the extra effort?
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.
ACK.
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.
I'd probably not go as far as to eagerly _remove_ all support for 32-bit as in RM'ing existing packages that still build and work fine. I'd rather like to see such a policy change to illustrate a common position that we'd rather disable an architecture and RM its binaries rather than fix a non-trivial issue on that platform, which might block a testing transition or cause some other roadblocks for the archs we actually care about. I know that many others in Debian care about their specific niche architecture and would be offended at some random maintainer just dismissing their subjectively reasonable request to fix things. Making it known beforehand where Debian Med puts its focus would help in making such situations feel less personal.
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".
Nice, didn't know about these virtual packages before. Makes sense for new packages -- would this result in an equivalent effect as restricting the "Architecture" list in all binary packages?
Removing architectures in existing packages:
[...] This approach looks good. As I said, I'd rather only go this way if the maintainer in question notices that there is a need to do so. I agree that if it turns out that for a package to be removed there are reverse dependencies outside of Debian Med's maintainership which would be affected, we would need to coordinate with the maintainers of these reverse dependencies. My gut feeling says these cases will be exceptional though. I think it could also make sense to think of what to do for other architectures that are not yet covered in Michael's proposal, such as (subjectively) obscure archs that still are considered official releasearchitectures (riscv64, mips64el, ...) or all the non-official architectures (alpha, hurd-*, m68k, ...)?
Cheers Sascha
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature