On 30/03/2024 01.00, Diane Trout wrote:
On Thu, 2024-03-28 at 14:51 +0100, Michael R. Crusoe wrote:Like all policy proposals, this is not meant to be a hard rule for all time. We can and should revisit the issue later!What do you think of the policy being instead of "-med team packages MUST support all current Debian architectures", "-med team packages (CAN or SHOULD) try to support all current Debian architectures."
Thank you for introducing this phrasing. I don't think there is a current Debian-Med team policy on architecture support. And from what I can see, there is nothing in the policy of Debian itself that packages SHOULD or MUST support all official Debian architectures. I would suggest "-med team packages SHOULD try to support all 64-bit little-endian architectures. Team packages are allowed to exclude 32-bit and/or big-endian architectures without justification." More details in the MR that I am preparing.
Many packages do work fine, but some make no sense without being able to access much more than 4G of memory or have picky CPU architecture dependencies. I don't think the team should automatically turn off all more obscure architectures, but it seems very reasonable to be quite willing disable builds for things that cause problems outside of x86_64/arm64.
And riscv64, which I predict will be the next big architecture for scientific computing in a few years. Which is why I'm proposing that we cast a wider net using "64-bit and little-endian".
OpenPGP_signature.asc
Description: OpenPGP digital signature