[cl-debian] Anyone willing to package Cedilla?

[René van Bevern]

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é

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-debian/attachments/20050830/77ef8a5e/attachment.sig>