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
