Re: Removing dpkg arch definitions for powerpcspe?

[Guillem Jover <guillem@debian.org>]

Hi!

On Thu, 2025-09-04 at 14:48:05 +0300, Adrian Bunk wrote:
> On Thu, Sep 04, 2025 at 03:25:57AM +0200, Guillem Jover wrote:
> > About whether there's any necessity to remove architectures, yeah, we
> > could leave them around, but that also has a cost in that it is
> > confusing to expose things that are currently not viable, and that
> > people might end up trying to support and end up placing in package
> > metadata for example, or tooling.
> 
> Please correct me if I am wrong, but aren't there issues when dpkg on 
> ftp-master does not know about an architecture in the Architecture field?

> Would dak on ftp-master running forky reject uploads of trixie packages 
> like libreoffice or qemu?

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.

Thanks,
Guillem