Bug#591054: cl-asdf: circular dependency with common-lisp-controller

[Desmond O. Chang]

On Tue, Aug 3, 2010 at 12:14, Faré <fahree at gmail.com> wrote:
> On 2 August 2010 23:05, Desmond O. Chang <dochang at gmail.com> wrote:
>> The cl-asdf dependency of c-l-c is hardcoded in debian/control, the
>> c-l-c dependency of cl-asdf is generated by dh_lisp when building.
>>
>> Installing c-l-c does not depend on cl-asdf, but its code depends.
>>
> Apparently, all dh_lisp does for source code is run
>  clc-update-customized-images
> which recompiled "customized images" that use the library.
>
> But I see nothing to produce those "customized images".
> Is anyone using this feature? Probably not.
> This possibly makes the whole thing a red herring.
>
> Maybe we don't need common-lisp-controller at all?
> All we need is make sure every debian implementation can
> (require :asdf) and get a recent asdf2. Since asdf is self-upgradable,
> we don't need to enforce a same system-wide asdf2 for all implementations:
> you (require :asdf), and if you want whichever is system installed, you can
> (asdf:load-system :asdf).

c-l-c seems not only a asdf caller.  I think cl-asdf is different from
other cl- packages, because those packages all depend on it, it must
be loaded before any other package.  In current c-l-c mechanism, asdf
is compiled into implementation during the impl's installation.

>
>>> I believe that
>>> a- c-l-c should be simplified with respect to the newest ASDF2, and
>>> marked as depending on ASDF 2.004 or later.
>>
>> I'll do it.
>>
> Thanks!

c-l-c has been rewritten for a development snapshot of asdf2.  I just make
c-l-c depend on cl-asdf (>= 2:2.004-1).  Is it necessary to rewrite it
again?

>> The orig tarball is only required if the package is not debian native.
>> Do not put debian revision part in your version number [1], simply
>> increase the version number.  You can use `dch -i'.
>>
> That much I know. But how do you deal with the fact there is an orig tarball,
> that git-buildpackage knows how to build or rebuild it, but doesn't include
> it in its manifest so that neither dput nor dupload will upload it, whereas
> the mentors.debian.net daemon rejects the package because it thinks the
> tarball is missing. Or maybe in these cases you just don't go through
> mentors.

What are you building?  c-l-c?  It doesn't have orig tarball at all.