Re: Removing dpkg arch definition for arm64ilp32?
On Sat, 2023-11-11 at 23:52:21 +0000, Steve McIntyre wrote:
> On Sat, Nov 11, 2023 at 08:36:16PM +0000, Wookey wrote:
> >It was being used internally/developmentally for a while (at CISCO)
> >but, as you observe, only with large kernel and toolchain
> >patches. Various groups dragged their feet on this to disourage it
> >becoming a thing we'd all have to maintain for years. I was doing the
> >debian development at ARM at the time and the bootstrap was never
> >completed. A few people (largely just CISCO) wanted it quite
> >badly. Nearly everyone else thought it was not worth the maintenance
> >effort. No-one has asked about it for quite a few years now (last mail
> >Oct 2018) so I think we can assume that it is indeed dead and no-one
> >would notice for years/ever if you removed it from dpkg.
>
> +1 on the story and on dropping it.
Thanks for the background info! Ok then, I've queued its removal
from dpkg.
> >> For armeb, I assume it was properly upstreamed at the time, and it was
> >> actually used, even if it's currently not in use (like arm) I see tons
> >> of references in Sources files, and thus removing the arch definitions
> >> for either of these would not be safe right now I think.
> >
> >It is obsolete. It probably doesn't work any more having been unused
> >since the early days of the NSLU2/Sarge (circa 2006/2007). It might
> >still have been in use till 2011ish?. As you say it should probably be
> >removed from upstream sources before it is removed from
> >dpkg. Interesting question on how much effort (if any) (and when)
> >should be applied to tidying up stuff like this which is simply no
> >longer in use. If/when 'arm' is removed 'armeb' should certainly go
> >with it.
Sorry, I was probably not clear, with the "references in Sources
files" I meant mainly references in debian/control (in fields), that
trickle down into Sources repo indices, where on Debian, AFAIUI dak
might be unhappy about unknown architectures once its host gets
updated to a version of dpkg that does not list them (but perhaps
that's only on upload but not for existing ones in the archive). I
think that could be the main blocker for such removals. Whether
upstream kernels and toolchains might keep, drop, or lack support for
existing ports, could be indicators of their liveliness but I don't
think should be the only deciding factors, just important ones to
consider. (I'm thinking about the recent ia64 removal from Linux and
probably glibc for example.)
> armeb was mostly before my involvement in any arm stuff, as Wookey
> says. It did at least have some life as a functioning port, at
> least. I'd agree on leaving it in place for now, assuming it's not
> causing any trouble in terms of maintenance / support.
Ah, I just had a flash from the past, about chatting about the port
face to face with Lennert Buytenhek. :) For dpkg there's not really
much of a maintenance burden. My concern has increasingly been that
these (dead/unused) ports can confuse or be a burden instead to
diligent package maintainers, when they try to handle or list all
such ports in packages.
I've now also gone over the current dpkg arch definitions and tried to
locally restrict or remove obsolete/non-existing things, going from the
current «dpkg-architecture -L» list of 524 arches down to 238, and will
see what's safe to push out. :) Checking now for references to ports
such as arm or armeb in Sources indices does not look too bad (around
40 source packages for arm and 10 for armeb), so I might do a better
analysis and then check how these could be shadowed for linux-any (as
I also realized now these are part of the base CPU definitions which
cannot be removed as that would affect any other port), and perhaps
propose their shadowing too alongside a mass bug filing to remove
such references in a bit if people would like to see such cleanup
getting done, otherwise keeping them for a while also seems fine to me.
Thanks,
Guillem
Reply to: