update on CCL packaging status (resent)

[Faheem Mitha]

Hi Faré,

Sorry to put you to the trouble of having to explain this again. I'm
sure you have had to do it before.

On Wed, 11 Sep 2013, Faré wrote:

>> Can you elaborate on the reasons why looking to an external ASDF is
>> not a good idea? I assume that having multiple versions of ASDF in
>> the archive is Ok. This is done for lots of other packages.

> For the horror of ASDF1 days and its upgrade strategy, see
> http://fare.livejournal.com/149264.html

> The issue is: when an implementation comes with an updated version
> of ASDF that it depends on, then the packager of that implementation
> must update the ASDF package in debian, and make sure it works with
> all other packaged implementations. Oops. Now you have an expensive
> coordination problem. And if any implementation depends on patches
> that didn't make it to an ASDF release yet, you're really screwed.

> Also, now that ASDF 3 includes its own mechanism for self-upgrade
> and avoiding self-downgrade, and will automatically look at the
> debian-provided version if available (and unless told not to), you
> don't gain much, if at all, by doing these complex packaging tricks.
> Any time that your packaging tricks would have helped, ASDF 3 will
> already bring the same benefits at the tiny cost of loading an extra
> FASL for the newer ASDF. And then there are the times when the
> tricks come back to bite you in the ass, so let just ASDF 3 sort it
> out.

> In the bad old days of ASDF 1, few implementations shipped with
> ASDF, and those that did usually sported an obsolete
> version. Special packaging tricks for ASDF were not just useful, but
> necessary. These days are happily long gone.

Ok. I don't really understand the details, and I don't have a problem
with an internal ASDF.

But just to play devil's advocate, it is possible to have multiple
versions of ASDF installed simultaneously, right?

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?

>> In any case, the ftp masters will need to be ok with this.

> I don't see why not. ASDF needn't count as a library. Plus it's
> relatively small (depending on the implementation, the order of
> magnitude of the installed copy is 1MB), and copied only once per
> implementation, of which there are but a handful (in debian: sbcl,
> clisp, ecl, now ccl, formerly gcl).

Ok. I don't personally care, but if the ftp masters object (assuming
that the CCL package actually gets to the point of being reviewed by
them), then is it Ok if I point them to you?

BTW, the current status as you can see on the 609047 bug thread, is
that the ccl-ffigen package, which is used to build the interface
databases for CCL, was rejected by the ftpmasters as it was a copy of
GCC, or something. This happened in April, but I only just got around
to writing a response. You can see the email in the bug thread.

If I get around to updating the package to the current CCL, would you
be willing to test it?

> The only debian-packaged common lisp that doesn't work well with
> ASDF 3 is GCL, but then again, I believe GCL hasn't been re-packaged
> in Debian in quite some time. And it's not like it worked that great
> with ASDF 1, either. Also, it requires an old version of libgmp, if
> I understand correctly, and sorely needs some re-packaging.

> PS: it looks like current CCL trunk fails to pre-compile the
> asdf.lisp it packages. Unless you wait for them to fix that, you may
> want to do it yourself.

Any version of CCL that I package for Debian will be the release. So I
guess this is not an issue.

                                                        Regards, Faheem