Re: Removing dpkg arch definitions for powerpcspe?
Hi Guillem,
On Sun, 2025-09-07 at 04:11 +0200, Guillem Jover wrote:
> Yes, dak seems to validate architecture names from the .dsc Package-List
> field (which gets generated from the debian/control Architecture field,
> so arch restrictions in dependencies do not seem relevant/problematic),
> but my impression has been that it would indeed only reject new uploads.
> This can still be problematic, but if such an upload is required, then
> the obsolete arch references can be (in general) easily be removed from
> debian/control at that point as well.
>
> The way I see it:
>
> * removing arches is something that does not happen very often;
> up to now only three batches in two release cycles:
> - 1.17.x: removed lpia in 2014-10
> - 1.22.x: removed avr32, m32r, tilegx in 2023-08;
> removed arm64ilp32, uclinux-any, knetbsd-any; and
> restricted CPU wildcards for kfreebsd, kopensolaris, hurd,
> freebsd, dragonflybsd, solaris, darwin and aix into
> fewer arches in 2023-12.
>
> * these batches should ideally and in general happen early in the
> release cycle, which should give ample time to remove obsolete
> references.
>
> * only for architectures that are currently not in actual use
> or have never existed (so nothing in say Debian oldoldstable, or
> under LTS or ELTS, or similar).
>
> * removing them from dpkg first, means any thing like lintian,
> which uses or syncs its arch list from dpkg, will start emitting
> warnings/errors, and people can start removing references w/o
> need for a mass build filing; for example for the current batch,
> from the candidates, I see:
> - kfreebsd-* at least refs in 252 source packages,
> with 119 in Package-List.
> - kopensolaris-* at least refs in 3 source packages,
> with 3 in Package-List.
> - powerpcspe at least refs in 46 source packages,
> with 26 in Package-List.
>
> For the previous iterations in the 1.22.x cycle I did a bug filing
> pass, but I see now I left some non problematic instances for
> m32r (Build-Depends), hurd-alpha (Build-Depends) and
> kfreebsd-alpha (Build-Depends). And a problematic one for
> knetbsd-any (Architectue). I also see now there are also other
> pre-existing instances for architectures that have never existed in
> dpkg (such as avr, or any-x32). Will be filing reports for some of
> those.
>
> So once/if any of those candidates for the next batch get removed,
> I'd wait a bit in the release cycle, then start going over the
> remaining source packages and send patches to remove old refs.
Does removing architectures from dpkg really make such a difference that
it's necessary to do that so early after the architecture was dropped?
I personally think that we shouldn't drop architectures at all as to not
hamper projects like rebootstrap [1] which allow bootstrapping Debian from
source on any given architecture.
And if someone wants to bootstrap Debian for powerpcspe or ia64, for example,
why should we actively block that?
Adrian
> [1] https://wiki.debian.org/HelmutGrohne/rebootstrap
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: