Bug#609047: update on CCL packaging status (resent)
Dear Faheem, >>> 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. > > Sorry if I was unclear. I meant multiple cl-asdf Debian packages installed > simultaneously, corresponding to different ASDF versions. I.e. option (b). > You don't get it. The current, working, solution is to have *both* (a) one precompiled copy of ASDF with *each* implementation, and (b) optionally, *one* installed source copy of ASDF from package cl-asdf. This is a WORKING solution. Please don't change that until and unless you can propose another solution that actually works — and you understand enough of the problem that you can argue why it works, and why it assuages all existing concerns. > Here I am imagining a world where CL implementations don't have their own > private copy of ASDF. > Is it even possible? We *need* a precompiled ASDF in each implementation's binary package, anyway. And each implementation's upstream source package comes with an approved and tested version of ASDF known to work with it. Is what you really mean is that you believe you can improve on things by introducing a tight coupling between implementations and asdf, by replacing each implementation's source copy of asdf by the version from cl-asdf, at package build time? This sounds awfully complex, for precious little gain, and great problems introduced by this new coupling. > If I understand you correctly, (a) corresponds the case where the > implementations do have their private implementation. > Wrong. It's not an either/or. It's an and. Each implementation MUST provide a precompiled asdf for use with (require ...) and this CANNOT be done via package cl-asdf, only via each implementation's binary package. >>> 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've read the second sentence several times, but I don't get it. "Merge > patches upstream" implies there is a downstream. Are there multiple forks of > ASDF? Do the implementations develop/modify ASDF themselves? I got the > impression they just take some released version of ASDF and stick it in, > often only after been told by an ASDF maintainer. > Each implementation's copy of ASDF is conceptually a fork, and used to actually be, in the dark days of ASDF 1; in those days, there wasn't even a good common versioning system, and each implementation had patches over some unspecified CVS release of the official ASDF. Since the days of ASDF 2, the official ASDF maintainers (i.e. me) has been responsive enough about merging implementation-specific patches that implementations don't bother actively forking ASDF, but instead send their patches that get immediately integrated (or improved upon). Therefore, most implementations at most time include some stable release of ASDF (e.g. 3.0.2); at times, however, some implementations eager to release despite an incompatibility discovered in the upstream ASDF have shipped with a development version of ASDF (e.g. hypothetically, 3.0.2.5, still from the official version control), or worse, a locally patched version of ASDF (e.g. hypothetically, 3.0.2.2 plus some patch). >> 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. > > The latest CCL release. I don't think Debian cares, but it seems the > more natural thing to do. If it ever actually hits Debian, and enough > people want trunk instead, I could switch to trunk. > I don't have a strong opinion. >> Actually, this is an issue since CCL 1.6, that will hopefully be fixed in >> trunk soon — see http://trac.clozure.com/ccl/ticket/ > >> So, please make sure you pre-compile ASDF as part of your installation of >> the CCL. > > Ok, but I'll need instructions on how to do this. > cd $CCL_DEFAULT_DIRECTORY ./lx86cl64 --no-init --eval '(progn (compile-file "tools/asdf") (quit))' —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Laziness
Bug#609047: update on CCL packaging status (resent)
On Wed, 11 Sep 2013, Faré wrote: On Wed, Sep 11, 2013 at 2:03 PM, Faheem Mitha wrote: 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. Sorry if I was unclear. I meant multiple cl-asdf Debian packages installed simultaneously, corresponding to different ASDF versions. I.e. option (b). Here I am imagining a world where CL implementations don't have their own private copy of ASDF. If I understand you correctly, (a) corresponds the case where the implementations do have their private implementation. 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've read the second sentence several times, but I don't get it. "Merge patches upstream" implies there is a downstream. Are there multiple forks of ASDF? Do the implementations develop/modify ASDF themselves? I got the impression they just take some released version of ASDF and stick it in, often only after been told by an ASDF maintainer. 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. Great, thanks. 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? I'm like 100% sure Debian would not go for shipping the .cdb files from upstream, and I'd have to agree with them there. Anyway, generating the .cdb files is not a problem now, though it was ridiculously hard to get working correctly initially. No, the main issue is just that the ftpmasters don't like copies of libraries (or just software generally) that is already in Debian. And they considered ffigen to contain such a copy of gcc, though the outdated 4.0. In his email, Luca made the ridiculous suggestion that I should update ffigen for versions of gcc currently in Debian. 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. The latest CCL release. I don't think Debian cares, but it seems the more natural thing to do. If it ever actually hits Debian, and enough people want trunk instead, I could switch to trunk. 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/ So, please make sure you pre-compile ASDF as part of your installation of the CCL. Ok, but I'll need instructions on how to do this. Regards, Faheem
Bug#609047: update on CCL packaging status (resent)
On Wed, Sep 11, 2013 at 2:03 PM, Faheem Mitha 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/ 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
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
Bug#609047: update on CCL packaging status (resent)
>>> : Faheem Mitha >> Please let CCL come with its own ASDF 3, or maybe ASDF 2, if you're >> packaging the CCL release rather than trunk. > >> ASDF 3 is a big boy, and will upgrade itself to the version from debian, >> if available, and will know how NOT to downgrade itself, thank you. > > > Hi Faré. > > Sorry, I did not mean to distress you. > > I'm ccing Christoph and Peter in case they have comments. > > My reasons for suggesting this is that it is in line with Debian policy.that > says you should not have local copies of libraries already in the Debian > archives. > This policy makes a lot of sense for libraries, but does not make sense for ASDF, which is more of a library-loader, and in this case, is tied to the implementation. > 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. > 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). 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. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If a vegetarian eats vegetables, what does a humanitarian eat? — Mark Twain -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#609047: update on CCL packaging status (resent)
On Wed, 11 Sep 2013, Faré wrote: : Faheem Mitha The main outstanding thing that (probably) should be fixed before the CCL package itself is ready to be submitted to NEW is to remove the local copy of ASDF from CCL and configure CCL to look for the Debian installation of ASDF. I think at least Christoph Egger suggested this, and it is clearly a good idea. That's a totally crazy thing to do, of the kind of horror that was necessary in the days of ASDF 1. Please don't do it. If Christoph suggested it, he might have been traumatized in those days. Please let CCL come with its own ASDF 3, or maybe ASDF 2, if you're packaging the CCL release rather than trunk. ASDF 3 is a big boy, and will upgrade itself to the version from debian, if available, and will know how NOT to downgrade itself, thank you. Hi Faré. Sorry, I did not mean to distress you. I'm ccing Christoph and Peter in case they have comments. My reasons for suggesting this is that it is in line with Debian policy.that says you should not have local copies of libraries already in the Debian archives. Yes, I'd be packaging the release. 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. In any case, the ftp masters will need to be ok with this. Christoph/Peter/anybody, comments? Regards, Faheem
Bug#609047: update on CCL packaging status (resent)
>: Faheem Mitha > The main outstanding thing that (probably) should be fixed before the CCL > package itself is ready to be submitted to NEW is to remove the local copy > of ASDF from CCL and configure CCL to look for the Debian installation of > ASDF. I think at least Christoph Egger suggested this, and it is clearly a > good idea. > That's a totally crazy thing to do, of the kind of horror that was necessary in the days of ASDF 1. Please don't do it. If Christoph suggested it, he might have been traumatized in those days. Please let CCL come with its own ASDF 3, or maybe ASDF 2, if you're packaging the CCL release rather than trunk. ASDF 3 is a big boy, and will upgrade itself to the version from debian, if available, and will know how NOT to downgrade itself, thank you. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org In a free market there are no market failures, only market opportunities. In a bureaucracy there is no possible success, only a perpetual ever-worsening crisis. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#609047: update on CCL packaging status (resent)
retitle 609047 ITP: ccl -- Clozure CL owner 609047 ! thanks [Please CC responses to the bug report at 609...@bugs.debian.org] Hi, The current state of this package is reflected in the repositories https://bitbucket.org/faheem/ccl-debian and https://bitbucket.org/faheem/ccl-ffigen-debian The packaging is essentially done. Earlier this year Julien Danjou submitted ccl-ffigen to NEW, (ccl-ffigen is a build dependency on ccl) and it got bounced by someone on the FTP masters team with the following message: Date: Tue, 09 Apr 2013 21:00:37 + From: Luca Falavigna To: Debian Common Lisp Team , Faheem Mitha , a...@debian.org Subject: ccl-ffigen_1.2-1_amd64.changes REJECTED Hi, sorry, but we do not think introducing a convenience copy of gcc is a good thing. Also, the 4.0 sources contain files licensed under GFDL with invariant sections, which are not suitable for main. Please try to build your code using existing gcc versions in the archive implementing Built-Using field. Cheers, Luca === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. I think the writer misunderstood the point of the package, which is to build interface headers for ccl, and is pretty much hardwired to 4.0. Getting it to work for more recent versions of GCC is an extremely non-trivial task that I doubt anyone but the author of that code would attempt. I haven't had time to follow up on this, and I expect Julien is similarly busy. So there matters rest for the moment. The main outstanding thing that (probably) should be fixed before the CCL package itself is ready to be submitted to NEW is to remove the local copy of ASDF from CCL and configure CCL to look for the Debian installation of ASDF. I think at least Christoph Egger suggested this, and it is clearly a good idea. Feedback/comments welcome as always. Regards, Faheem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
