I no longer use Debian at home, and am currently on an obsolete Ubuntu at work (but might upgrade next month), so I am unable to create a debian package for ASDF 2.28 at this time. Someone from the Debian CL Team please create the package -- from the git repository, make debian-package should do it, though you may have to edit the debian/control, etc.
ASDF upgrades itself because it's the correct thing to do. The CCL 1.9 package MUST include an incompatibility with cl-asdf << 2.28, otherwise it's a bug in the CCL 1.9 package. More generally, each implementation's .deb package MUST include an incompatibility with ASDF older than that provided by the implementation. It is a bug that debian accepts a recent sbcl or ccl package without also having an updated cl-asdf package. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org War does not determine who is right — only who is left. — Bertrand Russell On Tue, Feb 12, 2013 at 11:19 AM, Faheem Mitha <[email protected]> wrote: > > On Tue, 12 Feb 2013, Faheem Mitha wrote: > >> >> On Mon, 11 Feb 2013, Christoph Egger wrote: >> >>> Hi! >>> >>> Faheem Mitha <[email protected]> writes: >>>> >>>> I'm not sure what to do about it, but bad interactions do concern >>>> Debian, I think. BTW, why do all Debian CL packages depend on cl-asdf? >>>> I think that is a misfeature, because it makes it difficult for users >>>> to use their preferred ASDF version. > > >>> Because all these cl-* packages "need" asdf. Can't the ccl one just be >>> made to work with debian cl-asdf? It just going to be pain with >>> everything shipping its own asdf (I know most other stuff does as well >>> :-( > > >> Well, my point is that since the implementations now ship their own ASDF, >> then the Debian ASDF is not necessary, since users can choose to use the >> internal ASDF shipped by their implementation. >> >> I'm not sure if this is a good idea or not for implementations to ship >> their own copy of ASDF, I would have thought probably not. One possibility >> is (no idea whether this is a good idea or a bad idea) to remove the >> internal copy of ASDF from CCL and patch upstream to point the >> implentation's `require` function to the external ASDF. The CCL upstream at >> least probably won't care, I think. This would also have the advantage that >> the ASDF used could be kept up to date. > > > It seems Policy supports this. I asked on #debian-mentors, and Paul Wise > pointed me to http://wiki.debian.org/EmbeddedCodeCopies > > Policy 4.13 says in http://www.debian.org/doc/debian-policy/ch-source.html > > 4.13 Convenience copies of code > > Some software packages include in their distribution convenience copies of > code from other software packages, generally so that users compiling from > source don't have to download multiple packages. Debian packages should not > make use of these convenience copies unless the included package is > explicitly intended to be used in this way.[29] If the included code is > already in the Debian archive in the form of a library, the Debian packaging > should ensure that binary packages reference the libraries already in Debian > and the convenience copy is not used. If the included code is not already in > Debian, it should be packaged separately as a prerequisite if possible. [30] > > This seems to apply here. The proviso "unless the included package is > explicitly intended to be used in this way" is apparently intended for cases > where the included library does not exist in a separate standalone form. > > If you guys think pointing CCL to the external Debian ASDF is reasonable, > I'll ask upstream. Let me know. > > >> BTW, see https://bugs.launchpad.net/asdf/+bug/1120998 > > >> I don't understand why ASDF is attempting to upgrade itself like this. >> I've never heard of such a thing before. Do any of you understand why? > > > Regards, Faheem _______________________________________________ pkg-common-lisp-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-common-lisp-devel
