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 <psequei...@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@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-common-lisp-devel _______________________________________________ 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
