Bug#609047: update on CCL packaging status (resent)
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
Reply to: