Re: Removing dpkg arch definitions for powerpcspe?

On Sun, Sep 07, 2025 at 04:11:10AM +0200, Guillem Jover wrote:
> 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.

This sounds like a lot of potential pain for near-zero benefits.

Like we might end up with an oldstable upload to security-master that 
gets built and a DSA published, but then ftp-master refuses to import
the packages from the DSA for the next point release.

powerpcspe, kfreebsd-amd64, kfreebsd-i386 and ia64 were until recently 
actively maintained in ports.

This implies that the arch definitions are used in a gazillion places.

Even kopensolaris is used in the Architecture list of a package in 
trixie that does have plenty of CVEs (grub2).

>...
>   * 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,
>...

I agree with you that obsolete architectures should eventually get 
removed, but I do not see the urgency to do it in this order.

IMHO best would be a deprecation process where lintian emits an error 
for architectures that should not be used in forky, and the actual 
removal happens when trixie gets removed from ftp-master.

The lintian tag could also be used to file RC bugs on the remaining 
packages in a year.

> Thanks,
> Guillem

cu
Adrian