On Sat, Sep 11, 2004 at 10:52:28AM +0200, Stefano Zacchiroli wrote:
> - naming issue.
>
> I need to understand what exactly contains the mod_caml distribution.
> AFAIK mod_caml is not an ocaml library per se, but rather an apache
> module in the spirit of mod-perl, mod-python and so on. If I'm right
> on this point I think you should not use the naming convention
> outlined in the debian ocaml policy, but rather the apache modules one
> which seems to be "libapache-mod-caml". For the same reason I don't
> see the point in having the -dev package.
>
> If I'm wrong however, and mod-caml contains some stuff which is useful
> as an ocaml library for itself even without apache, then I suggest to
> split the package in three packages instead of two:
> * libapache-mod-caml contains only the apache stuff
> * libapache-ocaml ocaml library, shared objects (if they exist!)
> * libapache-ocaml-dev ocaml library, all the rest
It's quite a complex tool so it comes in several parts. The key ones
are:
mod_caml.so - The module which is loaded into Apache, and contains
all the C code along with apache.cmo, cgi.cmo,
mod_caml.cmo.
Cgi_escape, Template - CAML modules which are most useful inside
mod_caml scripts, but could conceivably be used
independently.
Registry - An extension which is loaded into Apache (using the
CamlLoad command) to support CGI scripts.
Note the CAML bytecode which is actually linked into mod_caml.so.
This is because it makes no sense to distribute those cmo files
separately - a standalone program which attempted to use those files
would fail to even link.
registry.cmo is in /usr/lib/mod_caml/registry.cmo to avoid people
attempting to link to it as if it were a normal OCaml module (which it
isn't).
Then there are .cmi and .mli files for all of the above, which are for
developers only.
We also have icons (required by most scripts) and lots of example code
(for developers only).
Anyway, I've left the names the same for now (apart from fixing the
stupid bug in libapache-ocaml-dev.files - see below) because I don't
know what the name should be or what is an appropriate split of files.
> - package contents
>
> The distinction of stuff installed in the -dev and in the other .deb
> package seems to be ... rather casual :) This is probably because
> libapache-ocaml-dev.files erroneously contain a reference to
> /usr/lib/ocaml/3.07 (wrong version). I suggest to you each time you
> prepare some .debs to look at what is installed in one and what is
> installed in the other. You can do it or with dpkg --contents on the
> .deb or with mc (quite handy, you can look inside a .deb as if it is a
> directory)
Fixed.
> - lintian cleaness
>
> After having prepared a package it's really useful to use lintian both
> on the .dsc and on the generated .deb:
>
> $ lintian mod-caml_1.2.1-1.dsc
> $
Actually, when I do this I get:
$ lintian mod-caml_1.2.1-2.dsc
W: mod-caml source: cvsignore-file-in-source .cvsignore
W: mod-caml source: cvsignore-file-in-source examples/comments/.cvsignore
W: mod-caml source: cvsignore-file-in-source examples/simple-handlers/.cvsignore
W: mod-caml source: cvsignore-file-in-source examples/simple-scripts/.cvsignore
W: mod-caml source: cvsignore-file-in-source examples/useful-scripts/.cvsignore
These are definitely WON'T FIX :-) I like my .cvsignore files there.
> so far so good, but:
>
> $ lintian libapache-ocaml_1.2.1-1_powerpc.deb
> W: libapache-ocaml: image-file-in-usr-lib usr/lib/mod_caml/caml-icons/error.png
> W: libapache-ocaml: image-file-in-usr-lib usr/lib/mod_caml/caml-icons/ok.png
Fixed.
> W: libapache-ocaml: executable-not-elf-or-script ./usr/lib/apache/1.3/500mod_caml.info
My stupid bug in the mod_caml Makefile - fixed.
> E: libapache-ocaml: copyright-should-refer-to-common-license-file-for-gpl
Fixed, I think.
Also I get:
E: libapache-ocaml: unstripped-binary-or-object ./usr/lib/apache/1.3/mod_caml.so
Unfortunately I can't fix this. Stripping mod_caml.so removes the
CAML bytecode (there was discussion of this on caml-list a few weeks
back), and that is obviously a showstopper.
> I also suggest you to have a look at other libapache-mod-something
> package. I'm not an expert in apache related package, but probably there
> is some convention in those package that needs to be respected.
Actually I had a look at the mod_perl package, and came to the
conclusion that it's (a) big and (b) scary.
There are updates which fix everything I can see in SVN now.
Rich.
--
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
NET::FTPSERVER is a full-featured, secure, configurable, database-backed
FTP server written in Perl: http://www.annexia.org/freeware/netftpserver/
Attachment:
signature.asc
Description: Digital signature