Packaging CL libs and apps for debian
On Fri, Apr 25, 2014 at 6:32 AM, Dimitri Fontaine <dim at tapoueh.org> wrote:
>> That's fairly old. In practice, I recommend upgrading to the latest stable
>> when having trouble such as yours.
> I needed to upgrade for a test program I made using
> command-line-arguments that requires uiop?
Excellent. Are you using the new cl-launch 4.0.3?
(I see that the script for debian version 4.0.3 thinks it's 220.127.116.11 ? oops).
>>> Is that the intended way to use a debian packaged CL lib?
>> I believe so, though my understanding is the debian package CL
>> libraries are not that well maintained anymore. These days, all the
>> cool kids use quicklisp. Now, if you could write an automated
>> quicklisp to debian packager...
> I got it all to work together and made a very simple binary image using
> drakma to act as curl to check that I was on the good path. Then I added
> some more libs, as you can see at
> I'm not quite sure Quicklisp to debian package is the way to go, because
> of the Quicklisp release policy that I don't know of. Will talk about
> Xach about that.
Historically, the problem has been that there hasn't been a DD or DM
or set thereof
willing to *regularly* update a whole bunch of libraries.
It's a lot of work, and considering the fraction of lispers using Debian,
that might not have been the best use of a lot of time, either.
But now that Quicklisp provides us with regular updates of *everything*,
it might really make sense to *automatically* upgrade Debian based on Quicklisp.
Do you have access rights to upload a thousand packages to Debian every month?
> Again, my goal here is to package all the dependencies I need for
> pgloader and other CL programs I want to ship in debian, and I want to
> ship them in source and binary format. What I want is to be able to
> buildapp pgloader from sources all found within the debian repositories.
I suggest using different packages (maybe from the same sources)
for the source code and for precompiled applications
using a given implementation.
>> Back in the bad old days, c-l-c was trying to have a system cache.
>> This turned out to be a configuration and security nightmare.
> Ok. I don't think the docs have been updated to reflect what's currently
I admit I have stopped caring about c-l-c long ago;
the situation may have changed.
To solve the configuration and security nightmare is possible:
1- each debian-packaged implementation gets its feature #+debian-managed
2- the shared cache is defined in configuration files as predicated on
3- to avoid race conditions, precompiled variants exist in directories
with versioned named in /var
as precompiled-system's using compile-bundle-op, and override the
.asd in /usr/share/common-lisp
4- (harder) some new code using lib-op and/or dll-op combined with
image-restore-hook or some such
ensure that any cffi objects are loaded for systems
Since this is unhappily Debian and not NixOS, some amount of race conditions
and/or services being unavailable due to inconsistent system state
during upgrade is unavoidable.
>> I would recommend upgrading ASDF over trying to debug an old one.
> It wasn't even down to asdf here, I got it fixed, and I'm now in a
> position to be able to finish my libs packaging then build pgloader out
> of cl-* debian packages.
Excellent. Looking forward to the results.
Or then again ? go NixOS!
??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
"I've finally learned what `upward compatible' means. It means we
get to keep all our old mistakes."
? Dennie van Tassel