A Quicklisp Debian package

[Kambiz Darabi]

Hello,

first, I would like to thank you for your efforts and as a quicklisp and
debian/ubuntu user, give some comments

> 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.

I would also prefer not to have a special user.

> Second, I found the "swi" prefix a puzzling for a few minutes ...

I couldn't decode 'swi' until I read your post.

Although this is a valid point:

> 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.

in the past, I found myself installing the debianised package in the
first place to pull in the package manager dependencies (e.g. libraries
which are used with cffi etc.) and then use a newer version of the lisp
code.

> [..] 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.

+1

Thank you


Kambiz Darabi

Paulo Sequeira <psequeirag at gmail.com> wrote:
> 
> Sebastian,
>
> 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
> account.
>
> 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?
>
> Cheers,
>
> --
> Paulo
>
> [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
> -SWIQLISP_INSTALL='$SU -c "$INVOC $COMMANDS" $SYSUSR'
> LISP=$1
>
> # argument sanity checks
> @@ -45,8 +44,7 @@ if test ! -x "$LISP"; then
> fi
>
> # 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
> LOAD="quicklisp.lisp"
> -EVAL="'(quicklisp-quickstart:install)'"
> +EVAL="(quicklisp-quickstart:install :path \\\"$SYSUSR_HOME/\\\")"
> ERRLOG="/tmp/swiqlisp-setup_error.log"
> -COMMANDS="$load $LOAD $eval $EVAL $quit 2>$ERRLOG"
> -eval $SWIQLISP_INSTALL
> +COMMANDS="$load $LOAD $eval \"$EVAL\" $quit 2>$ERRLOG"
> +eval $INVOC $COMMANDS
>
> # check for errors
> if test -s $ERRLOG; then
> === END swiqlisp-install.patch ===
>
> _______________________________________________
> pkg-common-lisp-devel mailing list
> pkg-common-lisp-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-common-lisp-devel