Hi Paulo, First of all, sorry for the delay. I've been meaning to reply for some time now and your post to the Quicklisp mailing list was precisely the reminder I needed.
Secondly, I'm responding to both postings here *only* because cross-posting generally leads to confusion and the main issues up for discussion are Debian-specific. Quoth Paulo Sequeira on pkg-common-lisp-devel: > I'd definitely love to see a Quicklisp package for Debian. I think this could > be well aligned with the fact that many CL packages are being retired That's interesting. I wasn't aware of this 'policy'. > because of the desire of focusing efforts on implementations and some > essential packages (I also agree with this approach). I see. So the main effort by the Common Lisp Team is going into keeping the Common Lisp implementation packages up-to-date, correct? Virtual package 'lisp-compiler' is provided by the following packages: clisp, cmucl, ecl & sbcl Are there any other lisp implementations packaged for Debian that you know of? > I'd say that the essential contribution of the package would be to support a > site-wide, admin-controlled installation of Quicklisp packages. Quicklisp > already handles very well the installation for unprivileged users. More on this below. Quoth Paulo Sequeira Gutiérrez on quicklisp: > Just recently, the idea came that it would be nice to have a Debian package > for installing Quicklisp ([1] and [2]). First of all, a word or two about how this idea came about. As a Debian user for roughly ten years, when I heard that DebConf was coming to a city[1] near me[2] I decided it was time I went along, as a way of saying thank you and showing my support (if nothing else) for the OS and the people behind it. The question then was whether or not to attend DebCamp (the week preceeding the main conference). As you probably know, a work plan is required before you can attend DebCamp so I decided to submit an idea which had been simmering away at the back of my mind for some time; a Quicklisp Debian package. My proposal was accepted (despite the fact that I had no Debian packaging experience) and shortly after arriving at DebCamp I posted my request for comments on pkg-common-lisp-devel. If you've attended DebConf (or DebCamp) in the past you'll know what I mean when I say the whole experience was quite intense (in a good way, but intense nevertheless). To cut a long story short, Daniel Baumann (dan...@debian.org) offered to give me a crash-course in Debian packaging and then sponsor the result. Not surprisingly, the source package is called quicklisp: http://packages.debian.org/source/unstable/quicklisp http://packages.debian.org/source/testing/quicklisp The binary package is called cl-quicklisp: http://packages.debian.org/unstable/cl-quicklisp http://packages.debian.org/testing/cl-quicklisp Other quicklisp Debian package pages: http://packages.qa.debian.org/q/quicklisp.html http://lintian.debian.org/full/s...@sebyte.me.html#quicklisp http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=quicklisp All this to say that's it's already possible to issue the command 'apt-get install cl-quicklisp' (providing you're tracking the testing or unstable distributions), but don't expect much! In fact, all it does is: 1. pull in sbcl (unless another package which provides lisp-compiler is already installed) 2. install two files: /usr/share/cl-quicklisp/quicklisp.lisp /usr/share/doc/cl-quicklisp/README.Debian 3. display a helpful message (upon succesful installation) which reads: "To install Quicklisp in your home directory please read /usr/share/doc/cl-quicklisp/README.Debian" > For me, the main points for doing this is to have Quicklisp-controlled > packages installed system-wide, This was my thinking initially, but Quicklisp's design (focussed as it is on the user's home directory) seemed incompatible with apt-get (which requires root privileges) so we (Daniel and I) decided to keep things as simple as possible for the time being. > and to better advertise the availability of Quicklisp in Debian by having it > show up in Debian's package listings. I agree that a Debian quicklisp package will certainly increase the visibility of Quicklisp generally, which, needless to say, is a good thing. > However, I wanted to make sure first that this distribution & installation > method would not be fighting against Quicklisp's intended use and then to ask > for some advice on how upstream would deem reasonable for it to work. Quoth Zach Beane on quicklisp: > I can't imagine a mechanism for this to work in a nice way; this isn't to say > that a nice way is impossible, but that I lack imagination in this area. If > you have a mechanism in mind, I'd love to hear about it. I do have a mechanism in mind. More on this later. Regarding Quicklisp's intended use, it seems to me Quicklisp has a number of uses, some of which we would be going against and other's of which we wouldn't. For example, if a site-wide Quicklisp library update broke a users lisp program, they would not be able to revert to a known good version as they could if they were managing their own Quicklisp libraries. Conversely, Quicklisp is designed to greatly ease the installation of libraries and their dependencies and this would be as true for site-wide installations (performed by administrators) as it is for home directory installations (performed by unprivileged users). > For example, it seems to me so far that an assumption in Quicklisp's > design is that it should not have to deal or bother about file/ > directory permissions, nor take into account the possibility that some > systems could be installed by the sysadmin, as opposed to those > installed by an unprivileged user on his own. Is this correct? This is correct, yes, but I don't think this is necessarily a bad thing. Perhaps you can help here Paulo? Do you happen know whether or not we would be violating packaging policy if the postinst script were to create a system user cl-quicklisp, with home directory /usr/share/cl-quicklisp/, and then run a lisp (default sbcl) as that user? If not, we'd then be able to run the Quicklisp quickstart file as normal and Quicklisp proper would be installed under /usr/share/cl-quicklisp/quicklisp/, compiled files would end up under /usr/share/cl-quicklisp/.cache/common-lisp/... and all the postinst script would then have to do would be to install some init file code[3] which, when loaded, would somehow distinguish between Debian's site-wide Quicklisp libraries and a user's own Quicklisp libraries. Writing the site-wide Quicklisp init file code will be where the challenge lies. Lastly, it'd be really good to know whether or not you have time to collaborate on this Paulo. It will be much more likely to actually happen if you do :) Regards, Sebastian [1] Banja Luka [2] Istanbul [3] Probably similar in purpose to common-lisp-controller: http://www.cliki.net/common-lisp-controller although I haven't used CLC myself (nor studied the code in detail). -- 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
