Preliminary Debian packaging for Clozure Common Lisp (ccl.clozure.com)
Hi,
Please CC replies to my email address. Thanks.
I have put my preliminary packaging of CCL on Bitbucket as a Mercurial
repository, located at https://bitbucket.org/faheem/ccl-debian-tmp
Please test and report problem and suggest improvements. For
preference, open an issue.
This packaging is relative to the recommened release checkout from
svn, i.e.
svn co http://svn.clozure.com/publicsvn/openmcl/release/1.8/linuxx86/ccl
per the documentation in
http://ccl.clozure.com/manual/chapter2.2.html#obtaining-via-svn
2.2.3.2.2. Downloading a Release Version
which appears to be equivalent to the tarball in
ftp://ftp.clozure.com/pub/release/1.8/ccl-1.8-linuxx86.tar.gz
Instructions for use:
i) Checkout out CCL sources from svn or download and unpack the tarball.
ii) Copy the cloned repository into the source directory as the debian/
subdirectory.
iii) Run
debuild binary
or a similar command in the source directory to produce the
binary. See `man debuild`.
This packaging should be considered preliminary, because it is not in
a form that would be acceptable for the Debian archives. The sources
above contain precompiled binaries for the x86 and amd64 archs. Since
CCL is not currently in the Debian archive, and since CCL requires
itself to compile. it is necessary to use precompiled binaries from
somewhere.
I was informed that the correct way to address this is to use the
source without any precompiled binaries, and have some adjunct binary
packages which contain necessary precompiled binaries which bootstrap
the compiler. More about this later.
I have some queries and comments about this packaging. I'll divide
this into Debian-specific and CCL-specific questions. So, the former
may be of interest to Debian people, and the latter to CCL people.
First, the Debian-specific questions.
1) I'd like to take over the outstanding ITP for CCL (#609047,
cc'd). I've written to Darren Ho, the creator of this ITP, on 1st July
2012, (see http://bugs.debian.org/609047), but have not yet received a
reply. What else do I need to do, if anything?
I guess I need to get a sponsor at some point. When should this happen?
2) The main outstanding issue is how to handle the bootstrapping
issue, namely that CCL is not in Debian, but requires CCL to compile.
R. Matthew Emerson wrote in the openmcl-devel mailing list
#####################################################################
But, that said, what I myself actually do is this:
1. Check out the sources. I use the svn:// scheme so that I can
commit. (Note that the "publicsvn" component of the URL used for
the http: scheme is not used with the svn: scheme.)
svn co svn://svn.clozure.com/openmcl/trunk/source ccl
2. Get bootstrapping binaries from somewhere.
One way to get them is via the following checkout:
svn co --ignore-externals \
svn://svn.clozure.com/openmcl/trunk/linuxx86/ccl bootstrap cp
bootstrap/* ccl/
3. Get interface databases from somewhere.
cd ccl svn co svn://svn.clozure.com/openmcl/trunk/x86-headers svn
co svn://svn.clozure.com/openmcl/trunk/x86-headers64
#######################################################################
It looks reasonable to me to divide up the build requirements into two
separate pieces, as Matthew suggests, namely the source, and second
the bootstrapping binaries and the interface database. However, I'm
not sure about the details of how this should be done. Some specific
questions.
First, it seems that the source should be the only thing in
*.orig.tar.gz, per usual Debian guidelines. From what I have read, it
seems that the other two items (binaries + interface databases) should
be in a separate "special" binary package (or packages). There would
be several of these packages to cover all the different archs.
I think Debian prefers pristine upstream tarballs, but I have also
seen versions of software get packaged, so I assume there is no
problem packaging the results of `svn co
svn://svn.clozure.com/openmcl/trunk/source` as *.orig.tar.gz.
As regards the binary stuff, I'm less clear what to do with it. The
idea would be just to stick the binaries + interface into a binary
(deb) package. So, does there need to be a corresponding
*.orig.tar.gz, *debian.tar.gz and *dsc to create this binary, or not?
Also, can I put both of these into one package? If so what should the
package be called? And where should the files live? Would a package
name like ccl-bootstrap, and location like /usr/lib/ccl-bootstrap/ be
Ok?
Now the CCL specific questions:
3) My current package description for the package is
######################################################################
Package: ccl
Architecture: i386 amd64
Depends: ${shlibs:Depends}, ${misc:Depends}
Suggests: slime
Provides: lisp-compiler
Recommends: binfmt-support (>= 1.1.2)
Description: Common Lisp compiler and development system
CCL is a development environment for the ANSI Common Lisp language.
It provides a native-code compiler and an integrated debugger, as well
as all the features in the ANSI specification.
.
To browse CCL source definitions with development environments,
install the ccl-source package. For documentation on CCL's usage and
internals, the package ccl-doc, containing the CCL manual, is
provided.
######################################################################
I'm sure it is possible to do better than this. By way of comparison,
here is the SBCL description this is based on.
#######################################################################
Description-en: Common Lisp compiler and development system
SBCL is a development environment for the ANSI Common Lisp language.
It provides a native-code compiler and an integrated debugger, as well
as all the features in the ANSI specification.
.
SBCL also contains other extensions to the ANSI specification, including
a foreign-function interface, a pseudo-server API, user-extensible
stream functionality, a Meta-Object Protocol, and an ability to run
external processes.
.
To browse SBCL source definitions with development environments,
install the sbcl-source package. For documentation on SBCL's usage
and internals, the package sbcl-doc is provided.
######################################################################
Feedback from CCL experts welcome.
4) Debian requires a copyright statement, which is located in the
"copyright" file in the repository. On installation it is installed in
/usr/share/doc/pkgname/copyright. Here is the current text, taken from
the openmcl package that was in Debian a few years ago.
###################################################################
This is a Debian prepackaged version of Clozure Common Lisp. The
source code was obtained from ftp://ftp.clozure.com/.
Upstream Authors: Gary Byers <openmcl-devel at clozure.com> and Digitool,
Inc
Copyright (C) 1994-2003 Digitool, Inc
OpenMCL is licensed under the terms of the Lisp Lesser GNU Public
License (LLGPL). The LLGPL consists of a preamble (see below) and the
Lessor GNU Public License 2.1 (LGPL-2.1). Where these conflict, the
preamble takes precedence. OpenMCL is referenced in the preamble as
the "LIBRARY." On Debian systems the complete text of the LGPL 2.1 is
in the file /usr/share/common-licenses/LGPL-2.1. The preamble is
located in the file doc/LICENSE, in the CCL sources, and it is
reproduced verbatim below.
[this is followed by the preamble text]
####################################################################
Developers, please comment on this text as appropriate. In particular,
the copyright information is probably out of date.
5) The doc/src/makefile-common that builds the manual could use a
little TLC. Specifically, the `make all` target does not make the
multi-page html version of the manual, for no reason I can think of,
though it *is* built by the `make install` target.
I'm not sure what the
(cd .. ; $(SVN) commit -m "updated" ccl-documentation.html)
line is supposed to do. I assume this is for internal use. Also, the
`make clean` target for this makefile doesn't actually clean the
generated targets as one would expect, namely
doc/ccl-documentation.html, doc/src/ccl-documentation.html and
doc/manual, but only the build directory in which the single-html page
version of the manual is built.
IMO, having an install target here is a little bit out of
place. Usually the install target is for when a generated binary is
being written to somewhere on a system, but here it is just being
written somewhere else in the source tree.
Since your current install target does two things, namely copy
doc/src/ccl-documentation.html to doc/ccl-documentation.html, and
generate doc/manual (not counting the svn commit thing), I suggest you
get rid of the install target, (unless you want it for the svn
commit), and move these to `make all`. Then get rid of the two copies
of ccl-documentation.html, and just have the $(HTMLFILES) target move
ccl-documentation.html from the build directory to
doc/ccl-documentation.html.
On a tangential note, the source should probably not contain
doc/ccl-documentation.html, which is a generated file.
Regards, Faheem
Reply to: