Upgrade failures for asdf-3.1.7 and later

[Faré]

On Thu, May 4, 2017 at 1:01 PM, James M. Lawrence <llmjjmll at gmail.com> wrote:
> This part could be improved: "startup scripts should load, configure
> and upgrade ASDF among the very first things they do". Let's not tempt
> the user to configure before upgrading!
>
This works perfectly with ASDF 3 or later.

The reason you have a problem is because you are using software well
past its "best use before" date, that is thoroughly bitrotten.


> Another bullet says, "Now that all implementations provide ASDF 3.1 or
> later...", but that's not true. LispWorks PE does not. Yes, it's LW
> version 6.1.1. And CLISP does not, though I understand that situation
> is somewhat forlorn.
>
I'll specify "all ***maintained*** implementations", i.e. having had a
release since 2014. LispWorks PE is not a maintained implementation,
it's a 5 years old demo from 2012. Don't expect much from it. If you
are unhappy with it, please take irt to your friendly LispWorks
representative, not to asdf-devel.

CLISP hasn't been released for 7 years. Still, the better software
distributions (e.g. debian-based) use a recent hg checkout that does
provide ASDF, or otherwise bundle a recent ASDF with it. (I see that
NixOS uses the tarball; that's a mistake, I'll file a bug.) If that
doesn't satisfy you, take it to the clisp mailing-list or file a bug
against your favorite software distribution.

If you are hit by a bug in Quicklisp (that gives you an unusable ASDF
2.26), then complain to Zach, not to asdf-devel.

Your problem is not our problem. ASDF 2 is unsupported, except for
upgrade, which itself is only supported if you follow the upgrade
instructions in the manual. And even then, we recommend instead
replacing your implementation-provided ASDF 2 with ASDF 3.

When you meet users who are experiencing known bugs with 5-year-old
versions of your software, what do you tell them? Does your manual
document a live upgrade procedure?


> Here's the reason all this is immensely unexpected.
>
Any expectations founded on the premise of LispWorks PE are deeply flawed.
Tell your users not to use 5-year old crippleware.

> If upgrading on
> the fly requires reconfiguration, then I wonder what the purpose of
> upgrading on the fly is supposed to be. Now that I understand that
> caveat, I don't know why the on-the-fly feature exists. If one already
> has such control over the configuration, then one wouldn't have loaded
> ASDF2 in the first place The whole purpose of on-the-fly upgrades, it
> seemed to me, was to handle the case where such control has passed.
> For example the situation I mentioned: the user has the bog standard
> Quicklisp setup in their init file and, after running an image for
> some time, needs to load an ASDF3-only library.
>
Obviously, you have control over the configuration, since you are
using the central-registry (which you shouldn't be using in the first
place). It is logically impossible to use the central-registry without
controlling the configuration. And since you do, then you can upgrade
ASDF as recommended in the manual instead of whichever wrong way
you're doing it. Live upgrade from ASDF 2 works, but only if you
follow the instructions.


PS: Anton, would you have time to run cl-test-grid using ASDF 2.26,
making sure that it is loaded before and instead of whatever the
implementation provides, and not otherwise upgraded afterwards? That
would be informative. At least CFFI and plenty systems that I have
written or contributed to in the last two or three years depend on
ASDF 3 (and more recently often 3.1), plus anything that depends on
them.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Keynesians: see how much more Cuba has benefited from Sandy's desolation?
How blessed is it with that great natural resource, Hurricanes!