Source: cmucl Version: 21d-1 Currently, cmucl is only available on i386. 10 years ago this was perhaps excusable, but today this is a sign of a package that is stuck in the past, full of legacy cruft, and not in widespread use[1]. It certainly cannot be anything other than a non-leaf package for any important packages given foreign dependencies are not permitted on Debian's buildds[2]. That's all before you get to non-x86 architectures such as 32-bit and 64-bit Arm. Its popcon is currently 0.02% if you take the highest across any of the metrics.
I believe it is a waste of project resources to continue supporting such packages and that they should be left behind rather than trying to drag them kicking and screaming into the present. If someone is sufficiently motivated to go and add full amd64 support then they should go ahead, but otherwise I am of the view that it is time to admit that the package no longer is of sufficient worth for Debian. Jess [1] Upstream does not seem to believe in 64-bit computing and itself claims that doing a 64-bit port would be hard[2]. The former is no excuse to not support the native execution mode of almost all general-purpose consumer hardware that has been for sale in the past 10 years, regardless of personal belief (whether or not it's recommended for performance reasons is a different matter, though I'd be astounded if i386 code performed better than amd64 code due to the pathetic register file size of the former; if pointer size is really a concern there's nothing stopping it having a 4 GiB heap for its lisp environment and using a 32-bit index with the 64-bit heap base pointer). The latter is a sign that the code is poor quality and has baked-in assumptions about pointers being 32-bit integers. [2] In fact it has zero reverse dependencies and so can be removed from the archive with zero disruption. [3] https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/75