Lesson: Don't consider an idea a good one until you've slept on it and woken up
stil thinking it's good.
Perhaps not everything I proposed yesterday is nonsense, but the idea of
maintaining a one-to-one correspondence between binary ql-* packages and
individual Quicklisp libraries is the stuff of dreams, for one obvious reason -
there's no easy way of mirroring Quicklisp's excellent dependency handling in
dpkg without repackaging each Quicklisp project as a Debian package, complete
with the same dependency information. In this case, Quicklisp can't be allowed
to pull in dependencies independently of dpkg, which is another way of saying
Quicklisp can't be used and we've gained absolutely nothing.
No, on second thoughts, using Quicklisp in conjunction with dpkg is simply not
workable other than to install a single package (cl-quicklisp) which perhaps
provides administrators with a script for performing site-wide Quicklisp
operations (as demonstrated) and users with a script for querying the state of
site-wide Quicklisp libraries, and is a Debian package that provides nothing in
the way of dpkg dependency handling really very useful?
The only other option is an automated process by which a functional subset of
Quicklisp projects are converted (upstream) to standalone Debian packages
complete with the same dependency information. This is a non-trivial task to
say the least, something only experienced Debian packaging wizzards should even
consider!
Sebastian
--
Emacs' AlsaPlayer - Music Without Jolts
Lightweight, full-featured and mindful of your idyllic happiness.
http://home.gna.org/eap
_______________________________________________
pkg-common-lisp-devel mailing list
pkg-common-lisp-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-common-lisp-devel
