On Fri, Apr 25, 2014 at 6:32 AM, Dimitri Fontaine <d...@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 _______________________________________________ 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
