On Wed, Sep 11, 2013 at 2:03 PM, Faheem Mitha <fah...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
