A Quicklisp Debian package

[Sebastian Tennant]

Quoth Paulo Sequeira <psequeirag at gmail.com>:
> I looked at your swiQlisp tool and found it to be working just fine for me.

Great!

> [...] I found that it already supports an optional parameter to specify the
> location where it is desired to install quicklisp.

If you checkout the latest version of swiQlisp[0], you'll see that I've got rid
of the system user and I've used the :path keyword instead.

However, this doesn't solve the issue of where the results of compilation
should be kept.  If we don't utilise a system user, the results end up under
/root/.cache/common-lisp/ which seems wrong to me, but perhaps it's OK if we
make it clear that this is what is going on.

More importantly though, running as root introduces a huge security hole and
means that we are relying completely on Zach Beane to vet all the code he
accepts into the Quicklisp distribution.

I've looked at instructing Quicklisp to simply download libraries, rather than
downloading them and compiling them (see 'install' versus
'install-and-compile') but a number of important Quicklisp librarieshave to be
compiled at installation time for their dependencies to be correctly handled,
so compilation is a requirement and I don't think this should be done by a lisp
image running as root!

Unless you can convince me otherwise, for this reason alone, I will soon be
reintroducing the system user.

> I created a patch[1] to your swiqlisp-install script that takes advantage of
> this parameter and perform the install to the same directory as your original
> version, but without resorting to create the special user account.

Patch applied, but it was corrupted[1] and had to be fixed before it would play
nicely with 'patch' or 'git apply'.

It might help to send future patches as attachments (rather than inline)
although I wouldn't be surprised if they are still corrupted by the email
system somehow.

Alternatively, you could try using the standard github collaboration model[2].
This is probably best if you're going to get more involved (which I hope you
do).

While we're on the subject of workflow, I propose that we move discussion on
swiqlisp development to github[3] as none of this is Debian specific - swiQlisp
is the upstream project and at some point one of us should take the lead in
developing a Debian swiqlisp package.

> Second, I found the "swi" prefix a puzzling for a few minutes at first, and
> then realized it meant "system wide install".

It could mean that.  I think of it as simply Site WIde QuickLISP (pronounced
'swiklisp').

> I think the prefix can be dropped for the most part: installation directory
> can be /usr/share/common-lisp/quicklisp, user callable shell script could be
> simply named /usr/bin/quicklisp, and so on.

I don't agree.  'apt-get install quicklisp' is counter-intuitive to anyone who
knows how Quicklisp works.  My choice for the name of the binary package would
be swiqlisp, but we can cross this bridge when we come to it.

> Finally, I've been trying to figure out how to approach the interaction
> between SWI-quicklisp

The source package is called swiqlisp (and this isn't going to change), so
let's just call it that for now.

> [...] any quicklisp-managed system always takes precedence over traditional
> dpkg-managed ones. Anyone disagrees?

Isn't this something that individual users can decide, given it depends soley
on the order in which pathnames occur in ASDF:*CENTRAL-REGISTRY*?

At the moment, swiqlisp-install optionally appends this line to to your
site-wide init file (e.g. /etc/sbclrc):

 (push #P"/usr/share/common-lisp/swiqlisp/installed-systems/"
       asdf:*central-registry*)


Feedback wwelcome.

Seb


[0] git pull   (git://github.com/sebyte/swiQlisp)

[1] Leading whitespace was removed from every line which included it and
    consecutive spaces had been replaced with a space followed by a unicode
    NO-BREAK SPACE character (code point: 0xA0).  Just to complicate matters
    further, for some reason your list posting was base64 encoded.

[2] fork my repo within github, clone your fork locally, hack locally, push to
    your remote fork, issue pull request - http://help.github.com/fork-a-repo/

[3] https://github.com/sebyte/swiQlisp/issues