Faré wrote:
- If the answer to #1 is "no," how bad is that, anyway? Does anyone
actually use ASDF from cl-asdf instead of getting it bundled from their implementation or installing from source? Maybe this package could simply go away?
cl-asdf used to be very important back in the bad old days of ASDF 1, when implementations didn't provide it (except sbcl, mostly), and configuration was its own hell that common-lisp-controller was trying to solve.
These days, most implementations (at least all those in debian?) provide ASDF, and thanks to ASDF 2, c-l-c doesn't have to anything to do anymore. It used to try to manage a system cache of fasls, but that was disabled after it was found to be a big security risk. The only correct way to do it would be with a daemon, that compiles from clean debian-managed systems using debian-managed implementations only, in a new process with a clean environment, etc. Since no one is interested in actually writing that, I would just retire c-l-c instead. cl-asdf itself is marginally useful, for cases when you need a more recent asdf than the implementation provides, but it's not as big a deal as it used to be.
I'm inclined to think that figuring out how to load ASDF from the cl-asdf debian package to override an ASDF that has been packaged with your implementation is no easier than doing so from cl.net. Indeed, it may actually be more complicated, since you have to figure out how to load from where the debian package puts asdf, instead of where you have put it in your own user directory.
So I suggest we just drop the cl-asdf package: the cost of maintaining it cannot be justified by the benefit it provides to the community.
That said, if the Debian community disagrees with me, I don't mind maintaining the debian packaging in the ASDF git repository. I just don't have the time and energy to take it that final step of maintaining an appropriate Debian build environment, building the package, and shipping it.
Best, R