Bug#980431: cmucl: Barely used and does not build on any modern architecture
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
Reply to: