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