Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages

"Michael R. Crusoe" <[email protected]> Sat, 6 Apr 2024 14:22:13 +0200
Newsgroups	gmane.linux.debian.devel.medical
Message-ID	<[email protected]>

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 (application/pgp-signature, 840 B)