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
Reply to: