Re: Removing dpkg arch definitions for powerpcspe?
Hi!
On Sun, 2025-09-07 at 20:00:12 +0300, Adrian Bunk wrote:
> On Sun, Sep 07, 2025 at 04:11:10AM +0200, Guillem Jover wrote:
> > 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.
The benefit, is that this removes confusing entries that are of no
current use, and avoids people ending up trying to still support them.
> 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.
This is indeed a valid concern, but see further below.
> powerpcspe, kfreebsd-amd64, kfreebsd-i386 and ia64 were until recently
> actively maintained in ports.
The difference for me is that these have no stable branches, so once
they disappear from ports they have no concerns for their continued
support in existing systems (as they cannot be upgraded any longer
anyway).
> >...
> > * 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.
This is the current and existing way where the tooling automatically
picks up the changes and automatically communicates that to maintainers.
> 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.
So, I've been thinking about this concern, and the problem with this
suggestion is that then either lintian would need to be modified to
mark specific architectures as deprecated (independently from dpkg),
or both dpkg and lintian (and any other arch tables consumer as well)
would need to be modified to convey when a certain arch is deprecated.
But if things need to be modified anyway, I think we should instead
modify the tool that is at the root of the problem, which is dak.
The problem is that dak is using the definition of present arches from
the dpkg in the host installation it is running on (whatever that is),
instead of a dpkg matching the target suite the upload is being uploaded
to.
This also has had the other consequence of needing to wait until an
arch defined in a dpkg in stable, before some references to new arches
can be added, which also seems rather inconvenient.
So, for now I've queued powerpcspe for removal for my next push (and
as I mentioned earlier in the thread, if someone has appetite in the
future to revive it, and support for gcc and glibc gets reinstated,
I'm happy to restore support for it in dpkg as well). And then I'll
ask the ftp-masters how to improve the dak vs dpkg arch situation.
(And if this cannot be easily improved we can always revert the
removals before the forky release.)
Hope, that cover the concerns.
Thanks,
Guillem
Reply to: