[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

A Quicklisp Debian package


I looked at your swiQlisp tool and found it to be working just fine
for me. I have the following comments about it in order to move
forward the discussion.

First, I must confess that I'm not comfortable with resorting to
create a special user to serve as the owner of quicklisp-installed
files. Given that the justification you indicated for this is that
running the quicklisp-install script as root would deploy the files to
the wrong directory, I looked a little further into this and luckily
found that it already supports an optional parameter to specify the
location where it is desired to install quicklisp. 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

Second, I found the "swi" prefix a puzzling for a few minutes at
first, and then realized it meant "system wide install". 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.

Finally, I've been trying to figure out how to approach the
interaction between SWI-quicklisp and other systems not controlled by
it (e.g. a user-level quicklisp installed the standard way, as well as
other systems for which Debian packages have been created and
installed via dpkg).

The easy case is when a user-level quicklisp installation is performed
as usual, because it seems to me that the expectation from the user
would clearly be that this intstallation would take precedence over
any systems installed by the sysadmin. I don't think we need to do
anything special (ASDF2 already supports this scheme of giving higher
priority to user-specific systems search paths).

But I've not found it so clear what the rules should be for clarifying
interaction of quicklisp-managed and dpkg-managed systems. I would
think it indisputable that quicklisp-managed systems would be more
abundant and up-to-date than dpkg-managed ones.

Following a logic similar as to why the user would like to have the
option to install selected systems by himself (e.g. to have available
packages not installed by the sysadmin, or to use/test newer versions
than those sanctioned by IT dep.), I would say that quicklisp-managed
systems would take precedence over dpkg-managed ones.

On the other hand, dpkg-managed systems would likely be better
tailored/configured out-of-the-box than quicklisp-managed ones. And I
would think that if a system available via quicklisp is also
debianized, it's because there's a real need to take pains to do so.
I'm thinking on systems with non-Lisp dependencies, like the CL-SQL
backends that require specific libraries to be installed in the system
to actually work. Thus, it could be argued that, if there?s ever a
dpkg-managed system installed along with other quicklisp-managed
systems, the the former (*and all its dpkg-managed dependencies*)
should take precedence over the later ones.

At this point, I can't help thinking in subtle interactions by
divergent versions of base systems in a single installation, but
perhaps now I'm splitting hairs. So, if simplicity is to save us from
muddling with too much minutiae, then I say that the sane overriding
rule would be to state that any quicklisp-managed system always takes
precedence over traditional dpkg-managed ones. Anyone disagrees?



[1] === BEGIN swiqlisp-install.patch ===
diff --git a/swiqlisp-install b/swiqlisp-install
index 6784333..06de2dc 100755
--- a/swiqlisp-install
+++ b/swiqlisp-install
@@ -27,7 +27,6 @@

source swiqlisp.rc
source swiqlisp-utils

# argument sanity checks
@@ -45,8 +44,7 @@ if test ! -x "$LISP"; then

# create system user (suppressing the warning emitted if user exists)
-adduser --quiet --system --home $SYSUSR_HOME \
- ? ? ? ?--shell /bin/sh --disabled-login $SYSUSR
+mkdir -p $SYSUSR_HOME

# check for system user home
if test ! -d $SYSUSR_HOME; then
@@ -120,10 +118,10 @@ mkdir -p installed-systems

# install Quicklisp
+EVAL="(quicklisp-quickstart:install :path \\\"$SYSUSR_HOME/\\\")"
-COMMANDS="$load $LOAD $eval $EVAL $quit 2>$ERRLOG"
+COMMANDS="$load $LOAD $eval \"$EVAL\" $quit 2>$ERRLOG"

# check for errors
if test -s $ERRLOG; then
=== END swiqlisp-install.patch ===

Reply to: