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

[Faheem Mitha]

On Wed, 11 Sep 2013, Faré wrote:

> On Wed, Sep 11, 2013 at 2:03 PM, Faheem Mitha <faheem at faheem.info> wrote:

>> 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).

Here I am imagining a world where CL implementations don't have their own 
private copy of ASDF.

If I understand you correctly, (a) corresponds the case where the 
implementations do have their private implementation.

>> 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.

>> 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?

> Of course.

Great, thanks.

>> 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.

> I saw that. As a fallback, could you "just" consider the bootstrapped 
> .cdb files as "source"? Or is the issue due to your trying to build more 
> .cdb files than CCL usually comes with?

I'm like 100% sure Debian would not go for shipping the .cdb files from 
upstream, and I'd have to agree with them there. Anyway, generating the 
.cdb files is not a problem now, though it was ridiculously hard to get 
working correctly initially. No, the main issue is just that the 
ftpmasters don't like copies of libraries (or just software generally) 
that is already in Debian. And they considered ffigen to contain such a 
copy of gcc, though the outdated 4.0. In his email, Luca made the 
ridiculous suggestion that I should update ffigen for versions of gcc 
currently in Debian.

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

> Most gladly. 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.

>>> 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.

> 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.
                                                          Regards, Faheem