Packaging CL libs and apps for debian

[Faré]

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 4.0.2.3 — 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
>
>   http://pgsql.tapoueh.org/cl-debian/
>
> 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
> happening.
>
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
#+debian-managed
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.
Go NixOS!

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