errors with ccl 1.9 rc1
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
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 <faheem at faheem.info> wrote:
> On Tue, 12 Feb 2013, Faheem Mitha wrote:
>> On Mon, 11 Feb 2013, Christoph Egger wrote:
>>> Faheem Mitha <faheem at faheem.info> 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. 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. 
> 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