[CM] CLM versions

Fernando Pablo Lopez-Lezcano nando@ccrma.Stanford.EDU
10 Oct 2003 12:36:42 -0700


> > > then if there is here any debian user i have a question/poll...:
> > > which one of this two options would you prefer:
> > > 1)a package with the lisp image
> > > or
> > > 2) a package with source that compiles while clm is installed?
> > > 
> > > my personal preference goes for 2), and that is how it is packaged right
> > > now. 
> > 
> > Any reason why? 
>  
> one reason, the main reason..maybe the only reason..:-), is that
> Debian distribution has packaged 3 different Lisp flavours
> (cmucl,sbcl,clisp), so rather than forcing users to one lisp, lisp
> extra packages and extra libraries are distribued as sources that get
> compiled at installation time.

Ok, so it is a "debian thing" then... not only cm/clm/cmn but other lisp
debian packages do this. 

> In the clm case this package has "depends" on cmucl, which is the lisp
> i use and that i have tested, but of course my idea is to update the
> script and get "depends" on cmucl | sbcl | clisp
>  
> well another reason here:
> there is also the ALSA/OSS possibility. Debian supports both, and,
> even if i compile with ALSA as default there might be OSS users
> around, so with a script i provide they are able to recompile quickly.
>  
> Said this i should then provide so many alternative lisp images...
> clm-cmucl clm-cmucl-alsa (then sbcl and clisp)
> plus later clm-cmn-cm and all the possible combinations...
>  
> Of course if there is a solution to that i would consider it.

I don't think there is another solution. In Planet CCRMA I provide
separate prebuilt packages for clisp and cmucl so the user still has a
choice (and I used to provide OSS versions as well but then Planet CCRMA
became sort of ALSA only - with OSS emulation of course - so I dropped
those). I'm currently generating clm, cm-clm and cm-clm-cmn packages for
both cmucl and clisp, but in the end I think just cm-clm-cmn should be
enough, I don't think anybody would _not_ want the other parts... the
package is bigger but that's all (functionality of the individual parts
is not affected).

Anyway, if "build on install" is the Debian way go for it... :-)
-- Fernando