Upgrade failures for asdf-3.1.7 and later

Faré fahree at gmail.com
Wed May 3 19:19:58 UTC 2017


This is totally intentional and well-documented.

Do NOT use the central-registry if you don't know what you're doing. Use
the source-registry as recommended. (Or, if you truly insist, reinitialize
the central-registry after upgrade; upgrading from ASDF 2 will create a
fresh ASDF package; see asdf/tools/load-asdf.lisp for how to load ASDF
while supporting backward compatibility back to ASDF 1 the hard way).

Do NOT use ASDF 2.26 (from October 2012), ever. Help me convince Xach to
stop distributing that bitrotting piece of maintenance nightmare.
Seriously, it's a shame that Quicklisp isn't distributing ASDF 3.1.7 (from
May 2016), which is the very stable culmination of the 3.1 series and works
great with all its systems. And I totally understand that Quicklisp must be
conservative and should not upgrade to the latest 3.2.1 (from April 2017)
yet. Considering how badly ASDF 2.26 now behaves when trying to load
systems from Quicklisp, I wonder if Xach even ever tests it; I bet not.
Alternatively, to show how utterly ridiculous his attitude is, convince him
to distribute ASDF 1.85 (from May 2004) instead, the perfect gem that Dan
Barlow bequeathed us (). Or no more recent 1.366 (from September 2009), the
last version wholly untainted by my code contributions.

-#f


On May 3, 2017 2:23 PM, "James M. Lawrence" <llmjjmll at gmail.com> wrote:

Starting with a bare lisp image (e.g --no-userinit --no-sysinit for
SBCL), the following signals a "component not found" error:

(load "asdf-2.26.lisp")
;;; or whatever system you want
(push #p"~/quicklisp/dists/quicklisp/software/alexandria-20170227-git/"
      asdf:*central-registry*)
(load "asdf-3.2.1.lisp")
(asdf:load-system "alexandria")

The first bad commit is https://github.com/fare/asdf/commit/3a9457a

I hope this wasn't intentional? Ideally an old asdf version would
never get loaded, but practically speaking it sometimes does (e.g. on
LispWorks PE and CLISP). And if that happens, thereafter one is unable
to load a system that requires asdf-3. The above case is a
whittled-down version of a quickloading problem.

Best,
lmj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20170503/772e26f8/attachment.html>


More information about the asdf-devel mailing list