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