update on CCL packaging status (resent)

Faré fahree at gmail.com
Wed Sep 11 16:14:37 UTC 2013


>>> : 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



More information about the pkg-common-lisp-devel mailing list