Hi,
Am Mon, Apr 01, 2024 at 09:12:49PM +0200 schrieb Sascha Steinbiss:
>
> > 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.
ACK. Finally also removing packages creates some work we finally want
to save. I think we should simply apply this policy to new packages and
those who start failing for whatever reason with no obvious fix / patch
provided.
> 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.
Fully ACK.
> > 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?
If we agree about the policy to restrict new packages to the said
architectures I'd recommend adding this to our package template[1].
> > 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.
Sure.
> 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
As long as these do not create any trouble its perfectly fine to support
these.
> all the non-official architectures
> (alpha, hurd-*, m68k, ...)?
Hurd will be available next year. ;-P
Kind regards
Andreas.
[1]
https://salsa.debian.org/med-team/community/package_template/-/blob/master/debian/control?ref_type=heads
--
https://fam-tille.de
