[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

update on CCL packaging status (resent)



On Wed, Sep 11, 2013 at 2:03 PM, Faheem Mitha <faheem at faheem.info> wrote:
> Sorry to put you to the trouble of having to explain this again. I'm
> sure you have had to do it before.
>
No problem.

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

> 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 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?
>
Of course.

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

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

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

??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
It has been my observation that most people get ahead during the time
that others waste. ? Henry Ford



Reply to: