[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#980431: marked as done (cmucl: Barely used and does not build on any modern architecture)

Your message dated Fri, 23 Jun 2023 15:36:03 +0000
with message-id <[🔎] E1qCipP-001hLw-9U@fasolo.debian.org>
and subject line Bug#1038934: Removed package(s) from unstable
has caused the Debian Bug report #980431,
regarding cmucl: Barely used and does not build on any modern architecture
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
980431: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980431
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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

--- End Message ---
--- Begin Message --- 
Version: 21d-2.1+rm

Dear submitter,

as the package cmucl has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/1038934

The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)

--- End Message ---
Reply to: