A Quicklisp Debian package

Tue Sep 27 13:21:24 UTC 2011

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 (daniel at 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/sdt@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