On 01/04/2024 21.12, Sascha Steinbiss wrote:
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.
Thanks!
[...]Support Debian-Med packages for 32-bit and/or big-endian architectures is not a good use of our limited resources.Agreed.
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?
Yes, but with the benefit that we don't have to add in new 64-bit/little-endian archs that appear, like that which has been done for riscv64 and loong64 quite often these last few years.
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 release architectures (riscv64, mips64el, ...) or all the non-official architectures (alpha, hurd-*, m68k, ...)?
For non-official archs within the context of Debian-Med, I just ignore them unless a simple patch is provided in BTS. They don't block migration to testing, so I don't think about them.
Cheers Sascha
OpenPGP_signature.asc
Description: OpenPGP digital signature
