Bug#617501: clisp does not run, claims to be missing a required file
On Fri, Mar 11, 2011 at 00:42, Peter Van Eynde <pvaneynd at debian.org> wrote:
> I'm all in favor of your work and I think that you are doing the right
> thing, but I'm missing the following:
> - documenting what lisp packages should do
> - documenting what lisp implementation should do
> - documenting how users can use this
> - documenting how DM/DD can test their packages
> - no breaking other packages
First of all, please read this:
> Related: I wanted to investigate how the 'new' clc is supposed to work,
> but I've noticed that the
> don't mention this new redesign. What do I need to do? How to I test this?
I have updated README.Debian in dh-lisp, but c-l-c not yet.
I plan to upload new c-l-c once all existing implementations no longer
depend on it.
> Why did you select this method? Given the fact that as I understand it
> updated implementations should only depend on cl-asdf, if at all, what
> is the role of dh_lisp in new implementations and why on purpose break
> all older implementations?
Most of implementations already have asdf2 internally. They don't
need to depend on cl-asdf. Of cource, user may install cl-asdf, this
will implement hot-upgrading for asdf.
The original purpose of dh-lisp is to install c-l-c into images of the
implementations. Now it's useless. Please consider removing dh-lisp
from all common lisp implementations and redebianizing them.
Here is a potential usage for dh-lisp in the future. For example,
stumpwm needs to be compiled and loaded into sbcl to generate the
documentation. By default, ASDF2 will put all fasl files in
$HOME/.cache/common-lisp/..., but, in many building environment, $HOME
I think DM can solve it by binding XDG_CACHE_HOME to /var/cache/, but
now, /var/cache/common-lisp is managed by c-l-c. Once c-l-c deteted,
/var/cache/common-lisp may be adopted by dh-lisp and used to build
debian CL package.