errors with ccl 1.9 rc1

[Faré]

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 <faheem at faheem.info> wrote:
>
> On Tue, 12 Feb 2013, Faheem Mitha wrote:
>
>>
>> On Mon, 11 Feb 2013, Christoph Egger wrote:
>>
>>> Hi!
>>>
>>> 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.[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