[cl-debian] Bug#382430: c-l-c installation of ecl does things wrong

[Faré]

Package: ecl
Version: 0.9i-2
Severity: normal

the c-l-c installation of ecl does a few wrong things:

(1) it uses the c-l-c version of asdf and not the ecl-provided one from
        /usr/lib/ecl/asdf.fas
 as a result it fails to include the make-build extension from ECL sources
        ecl-0.9i/contrib/asdf/asdf-ecl.lisp
 Solution (a) would be to (require 'asdf) from the c-l-c compiled image
 and not compile it in the c-l-c binary for ecl.
 Solution (b) would be to include asdf-ecl.lisp in the ecl package,
 and recompile it together with c-l-c's asdf.lisp when installing c-l-c.

(2) it somehow gets cmp.fas and sysfun.lsp to systematically load verbosely
 in a way that isn't hushed up by flag -q resulting in an unremovable banner
;;; Loading #P"/usr/lib/ecl/cmp.fas"
;;; Loading #P"/usr/lib/ecl/sysfun.lsp"
 which is quite annoying for programs that need produce controlled output.
 This is probably caused by the runtime loading of /etc/lispconfig.lisp
 by c-l-c. This banner should not be printed by quiet ecl scripts.
 Solution (2a) is to explicitly bind *load-verbose* to nil
 when loading /etc/lispconfig.lisp.

 Solution (2b) is to modify the c-l-c ecl startup to somehow hook
 the value of *load-verbose* on the -q flag. However, this requires
 modifying or overriding code from ecl-0.9i/src/lsp/cmdline.lsp and
 maintaining the result. Ouch.
 Solution (2c) is to hook into ecl's loading of a user resource file
 and replace it with the loading of a system resource file, say
        /etc/ecl/rc.lisp
 that in turn loads /etc/lispconfig.lisp then the user resource file.
 We would just prepend that path to *lisp-init-file-list* from
 install-clc.lisp, and writing the proper default code in /etc/ecl/rc.lisp
 Thus the usual parsing of -q and -norc applies to clc's ecl.

(3) compiling configuration files everytime can be a performance issue,
 in addition to requiring to load the compiler. We could instead have a
 mechanism such as cl-launch's compile-and-load-file to only recompile
 when needed (SLIME's doesn't try hard enough for ECL), and put
 c-l-c cached .fas variants of the files in *lisp-init-file-list* before
 the source variants. Also, we want it to not require users to do anything
 special for the fasl to remain in synch with their lisp configuration.
 Any hackish code should come precompiled as part of install-clc.lisp
 so as to avoid requiring costly recompilation at runtime when things change.
 Solution (3a) would be to only do that for the system-wide file, and
 have that system-wide file include provisions for recompiling itself
 and then loading the compiled contents, and do the same for
 lispconfig.lisp and user files. A bit of a hack.
 Solution (3b) would be to modify or override cmdline.lsp to do the
 compile-and-load instead of load. Costly to maintain.

(4) If we use a compile-and-load-file strategy for (3), then we might
 share code with cl-launch. This would mean having a dependency on
 cl-launch. It also means I should change cl-launch to install its file in
        /usr/share/common-lisp/source/cl-launch
 instead of
        /usr/share/common-lisp/cl-launch
 and produce a cl-launch.asd. I'll do that for cl-launch 1.85.

In any cases, problems (1) and (2) both interact badly with cl-launch,
and although cl-launch 1.84 now fully supports ECL, debian users need
        export ECL=/usr/lib/ecl/ecl-original
so as to use cl-launch with ECL. I should probably include detection of
that executable in cl-launch as a workaround to current breakage, since
I already kluge a lot of my way to supporting ECL in cl-launch.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16.9-blefuscu
Locale: LANG=en_US.iso-8859-1, LC_CTYPE=en_US.iso-8859-1
(charmap=ISO-8859-1) (ignored: LC_ALL set to e
n_US.iso-8859-1)

Versions of packages ecl depends on:
ii  common-lisp-controller    6.1            This is a Common Lisp source and c
ii  gcc-4.1                   4.1.1-9        The GNU C compiler
ii  libc6                     2.3.6-16       GNU C Library: Shared libraries
ii  libgc-dev                 1:6.7-2        conservative garbage collector for
ii  libgc1c2                  1:6.7-2        conservative garbage collector for
ii  libgmp3-dev               2:4.2.1+dfsg-3 Multiprecision arithmetic library
ii  libgmp3c2                 2:4.2.1+dfsg-3 Multiprecision arithmetic library
ii  libncurses5-dev           5.5-2          Developer's libraries and docs for

ecl recommends no packages.

-- no debconf information