Oh shit, that's right: it uses version-satisfies instead of version<= (which didn't exist at the time), and of course, 3.0.0 doesn't satisfy 2.26 because of the major version mismatch. Ouch. One solution would be that quicklisp be patched to accept asdf if #+asdf3 or (member :asdf3 *features*). Another solution that quicklisp itself be updated to use asdf3 and possibly version<= rather than version-satisfies, or not: I've added a minor version number that allows to have version "branches" that don't involve a new major version number. The last solution would be that ASDF be stuck forever in using 2 as its major version number. Maybe I should have done just that, because that's the only 100% backward compatible way. Then I should promptly rename ASDF 3.0.0 into ASDF 2.34.0 or some such. I don't like any of these solutions, and I feel stupid for not thinking about it earlier. Xach, any comment? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Most people think they need a ruler. Perhaps we should give them a fake one that doesn't actually do anything, and then they won't think about it. It is sort of like giving an infant a pacifier. — Perry Metzger On Thu, May 16, 2013 at 1:19 PM, Stelian Ionescu <sionescu@cddr.org> wrote:
On Thu, 2013-05-16 at 12:54 -0400, Faré wrote:
Works for me on asdf 3.0.0 and the latest sbcl on linux/x64 Did you use make to build a new asdf.lisp? Is there an old asdf.fasl polluting the build? Which version is it from? You can load it manually then query (asdf:asdf-version).
I figured out what's happening: I load ASDF before quicklisp, and quicklisp doesn't recognize "3.0.0" as being recent enough so it tries to load 2.26 which fails during upgrade.
-- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib