Bug#609047: update on CCL packaging status (resent)

[Faré]

Dear Faheem,

>>> But just to play devil's advocate, it is possible to have multiple
>>> versions of ASDF installed simultaneously, right?
>>
>> Depends what you mean by "installed", but I'll take it that you mean (a)
>> each installed implementation's precompiled asdf FASL. (b) the source-only
>> code installation (NO precompiled FASL) from the cl-asdf package, to be
>> compiled in each user's personal FASL cache with whatever implementation he
>> uses (if any).
>
>> These are different enough things that I wouldn't call them "multiple
>> versions of ASDF installed simultaneously". And the magic of ASDF 3 is that
>> you, the debian packager, need not do any magic about it anymore, like in
>> the bad old days of ASDF 1.
>
> Sorry if I was unclear. I meant multiple cl-asdf Debian packages installed
> simultaneously, corresponding to different ASDF versions. I.e. option (b).
>
You don't get it. The current, working, solution is to have *both*
(a) one precompiled copy of ASDF with *each* implementation, and
(b) optionally, *one* installed source copy of ASDF from package cl-asdf.

This is a WORKING solution. Please don't change that until and unless
you can propose another solution that actually works —
and you understand enough of the problem that you can argue why it works,
and why it assuages all existing concerns.


> Here I am imagining a world where CL implementations don't have their own
> private copy of ASDF.
>
Is it even possible?
We *need* a precompiled ASDF in each implementation's binary package, anyway.
And each implementation's upstream source package comes with an approved and
tested version of ASDF known to work with it.

Is what you really mean is that you believe you can improve on things by
introducing a tight coupling between implementations and asdf, by replacing
each implementation's source copy of asdf by the version from cl-asdf,
at package build time? This sounds awfully complex, for precious little gain,
and great problems introduced by this new coupling.

> If I understand you correctly, (a) corresponds the case where the
> implementations do have their private implementation.
>
Wrong. It's not an either/or. It's an and.
Each implementation MUST provide a precompiled asdf
for use with (require ...) and this CANNOT be done via package cl-asdf,
only via each implementation's binary package.

>>> And is it common (or is there even an actual known case) of an
>>> implementation depending on a patched ASDF? Or even being very
>>> sensitive to the particular ASDF version?
>>>
>> It is common for an implementation to depend on a recent enough ASDF,
>> whether patched or not. The ASDF maintainer (previously, me) is
>> usually quick enough to merge patches upstream, though ASDF release
>> can lag a month (or sometimes two) after such patch merge.
>
> I've read the second sentence several times, but I don't get it. "Merge
> patches upstream" implies there is a downstream. Are there multiple forks of
> ASDF? Do the implementations develop/modify ASDF themselves? I got the
> impression they just take some released version of ASDF and stick it in,
> often only after been told by an ASDF maintainer.
>
Each implementation's copy of ASDF is conceptually a fork,
and used to actually be, in the dark days of ASDF 1;
in those days, there wasn't even a good common versioning system,
and each implementation had patches over
some unspecified CVS release of the official ASDF.
Since the days of ASDF 2, the official ASDF maintainers (i.e. me)
has been responsive enough about merging implementation-specific patches
that implementations don't bother actively forking ASDF,
but instead send their patches that get immediately integrated (or
improved upon).
Therefore, most implementations at most time include
some stable release of ASDF (e.g. 3.0.2);
at times, however, some implementations eager to release
despite an incompatibility discovered in the upstream ASDF
have shipped with a development version of ASDF
(e.g. hypothetically, 3.0.2.5, still from the official version control),
or worse, a locally patched version of ASDF
(e.g. hypothetically, 3.0.2.2 plus some patch).


>> Are you packaging from trunk or from the latest CCL release?
>> I personally prefer trunk, but I can totally see a case for the release
>> branch.
>
> The latest CCL release. I don't think Debian cares, but it seems the
> more natural thing to do. If it ever actually hits Debian, and enough
> people want trunk instead, I could switch to trunk.
>
I don't have a strong opinion.

>> Actually, this is an issue since CCL 1.6, that will hopefully be fixed in
>> trunk soon — see http://trac.clozure.com/ccl/ticket/1111
>
>> So, please make sure you pre-compile ASDF as part of your installation of
>> the CCL.
>
> Ok, but I'll need instructions on how to do this.
>
cd $CCL_DEFAULT_DIRECTORY
./lx86cl64 --no-init --eval '(progn (compile-file "tools/asdf") (quit))'

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Laziness is mother of Intelligence. Father unknown. [Rumor has it it's Greed.]
    — Faré