update on CCL packaging status (resent)
Faré
fahree at gmail.com
Wed Sep 11 19:50:02 UTC 2013
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
More information about the pkg-common-lisp-devel
mailing list