[Asdf-devel] Wanted: Debian packager
>> 2. 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