Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Alternative proposal: COAN
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2003-02-25 (21:55)
From: Michal Moskal <malekith@p...>
Subject: Re: [Caml-list] Alternative proposal: COAN
On Tue, Feb 25, 2003 at 12:15:50PM -0500, Eric C. Cooper wrote:
> I have gotten into the habit of using apt-get for all the Perl modules
> I need to install, rather than going to CPAN.  The Debian maintainers
> have done the hard work of specifying the dependencies, install
> scripts, etc. so that it's easy to install and uninstall them.  I'm
> sure I get only a small subset of CPAN that way, but the quality
> control has been worth it, and I haven't needed anything that wasn't
> already Debianized.
> This is mainly valuable because it is the *same* apt-get tool used for
> everything on the system, not a parallel tool just for Perl.  It makes
> it easier for Perl applications to be mainstream rather than marginal,
> because other packages can easily and robustly specify dependencies on
> the Perl apps.
> For these reasons, a parallel tool just for OCaml would be less useful than
> packaging the relevant libraries as Debian packages (like Sven Luther and
> others have done -- thanks!)  But that doesn't help non-Debian OCaml users.

Look how much perl modules is debianized and how much ocaml modules is.
I can only give figures for PLD (rpms): ocaml - 29, perl - 961. Now this
is not mainly because there is lot more perl modules available. The main
problem is that for average perl package all you need to do to put it
into rpm is:

	%{__perl} Makefile.PL


	%{__make} install DESTDIR=$RPM_BUILD_ROOT

CPAN modules are standardized. That's the main advantage of them. We need
this kind of stuff for ocaml. 

What we should standardize? IMHO:

1. Naming conventions. Maybe some guidelines for package names. Anyway
   for package foo, version 1.2.3:
     - source tarball should be foo-1.2.3.tar.gz
     - it should unpack all it's files into foo-1.2.3 directory
   (these are good GNU practices anyway)

2. Build procedure. We can either use OCamlMakefile, ocamake, or
   some ocaml script. But make it standard for all COAN packages.
   Preferably makefiles should be generated or build process should be
   performed by a special tool, so it is possible for example to add
   DESTDIR support, or shared library support if it's added to ocaml,
   in one place instead of hundreds of COAN packages.

   In any event building COAN package should be matter of one command.
   And it should be the same command for all COAN packages.

3. Installation. IMHO packages should be installed to `ocamlc
   -where`/package-name. Installation tool, whatever it is,
   should support DESTDIR (i.e. specifying fake root directory).

4. Documentation. But this should be easy -- just use ocamldoc, 
   and maybe some additional files (in pkg-version/doc/).

5. Enforce META files for findlib?

6. Maybe some metafile describing package and dependencies? 
   From which .spec for rpm and makefile rules for debs could 
   be generated. Preferably in XML. Example:

<pkg name="mysql" 
  <short>MySQL bindings</short>
  <short lang="pl">Wiazania MySQL</short>
    This package provides bindings to MySQL server, blah... blah...
    <!-- 10 lines or so -->
  <long lang="de"> .... </long>
  <!-- We need to standardize this as well. -->
    <!-- packages from COAN: -->
    <coan-pkg name="foobar" version-not-less-then="1.23"/>
    <!-- maybe name="foobar >= 1.23" will be better? -->
    <coan-pkg name="foobar-baz" version-equal="1.23"/>
    <!-- system packages: -->
    <system-pkg name="ocaml" version-not-less-then="3.06"/>
    <!-- not mysql-devel or mysql-dev, just mainstream name -->
    <system-pkg name="MySQL" version-not-less-then="1.2.3"/>

Note that this does not overlap much with META-files. Intention is that
this meta.xml file should be distributed with sources, not generated
during build. META file might need to be generated (for example to embed
C linker option in it).

Just my 0.02PLN, mainly from packager point of view. In case I'm being
too rpmcentric, Sven please correct me :-)

: Michal Moskal ::::: malekith/at/ :  GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::: Wroclaw University, CS Dept :  {E-,w}-- {b++,e}>+++ h

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: