On 30.08.05, Juliusz Chroboczek wrote: Hello Juliusz,
I have one serious objection. Cedilla is an end-user application, not a Common Lisp library, so I believe the package should be called ``cedilla'', not ``cl-cedilla''. The end user has no interest in the programming language Cedilla is implemented in.
I highly agree on this. We have multiple End-User CL applications in the archive (mcvs, albert, stumpwm, maxima) that do not follow the cl- prefix either. cl- really only makes sense for the name of libraries.
More generally, shouldn't the CL-Debian project start thinking about deployment of applications? It seems completely oriented to libraries right now.
This is where implementations put some restrictions. Deploying Common Lisp applications is generally difficult. a) I just yesterday worked to integrate SBCL's and CMUCL's FASLs into Debian's binfmt-support, so that they are executable using the binfmt_misc kernel module. This is nice and fast for writing own system tools or even compiling larger applications, but it is completely unsuitable to deliver in a Debian package: the binary formats of SBCL und CMUCL change frequently and every package would need to be rebuilt if such an incompatible change happens. b) One could use the cl-libraries as build-depends, compile the application and dump an image to be loaded when the application is run. This is very fast, but if one of the cl-libraries has a real bug and it is fixed, the delivered application needs to be rebuilt to carry its new version in the dumped image. mcvs uses this approach and even delivers a whole clisp in its package. Applications delivered this way get huge in size, let alone the fact that you can not always load a dumped image that depends on foreign shared library code. c) The only real portable, code sharing and space saving approach is delivering the application in source code and registering it at ASDF and the Common Lisp Controller. Unfortunately this is also the slowest way. E.g. SBCL needs very much time to load even multiple of FASLs. And the first run takes even longer, because the package has to be compiled for many implementations first. Regards, René