Re: [Caml-list] Alternative proposal: COAN

[Sven Luther <luther@dpt-info.u-strasbg.fr>]

On Tue, Feb 25, 2003 at 10:48:33PM +0100, Michal Moskal wrote:
> 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.

This is because there are much more debian maintainers who package perl
stuff, than debian maintainers who package ocaml stuff. Also mostly we
prefer to package stuff we use, as it is much easier to do high quality
packages in these cases. And help is always welcome. I guess it is the
same for PLD too.

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

Note that debian packaging tools can handle unstandard source tarballs
without much problems, nice so we don't need to rebuild the tarball,
which modifies its md5sum.

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

Yes, DESTDIR support is a pain to add to each ocaml package. I don't
feel much like forcing a standardized build process though, not everyone
likes the same, as long as it supports changing the DESTDIR and has a
fairly easy build process, along the lines of configure, make, make
install. configure can be by editing a config file or preferably by a
configure script or a configure makefile target.

> 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).

Note, that i strongly advocate having two libdir directories, one,
/usr/lib/ocaml/<version_number>, for packages from the distrib, and the
second, /usr/local/lib/ocaml/<version_number>, for locally installed
packages. The first libdir would be given by -distwhere, and the second
by -where. findlib and such would default to the locale directory, but
could be overriden by the package maintainer.

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

Err, you are speaking about the debian/control files, we don't use
makefiles for such kind of information, only for building the package.

> <pkg name="mysql" 
>      version="1.2.3" 
>      url="http://foobar.com/mysql-ocaml/">
>   <short>MySQL bindings</short>
>   <short lang="pl">Wiazania MySQL</short>
>   <long>
>     This package provides bindings to MySQL server, blah... blah...
>     <!-- 10 lines or so -->
>   </long>
>   <long lang="de"> .... </long>
>   <license>BSD-like</license>
>   <!-- We need to standardize this as well. -->
>   <category>Bindings/Database</category>
>   <depends-on>
>     <!-- 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"/>
>   </depends-on>
> </pkg>

Well, first, i personnally don't like CML, but seriously, don't you
think that this format is a bit oververbose and incomprehensible for
just plain dependencies ?

For debian, we just have dependencies and build dependencies. Each of
those are listed in a field of the debian/control file, some of which
are dynamically generated at build time. As an example, lablgtk has the
following :

(* for the source package *)
Build-Depends: debhelper (>> 3.0.0), ocaml-3.06-1, libncurses5-dev, xlibs|xlib6g, debhelper, libgtk2.0-dev, libgtkgl2.0-dev, libglade2-dev, liblablgl-ocaml-dev (>= 0.99-3), librsvg2-dev
...

(* for the runtime package *)
Depends: ocaml-base-3.06-1,  ${shlibs:Depends}
...
(* for the developpment package *)
Depends: liblablgtk2-ocaml (= ${Source-Version}), ocaml-3.06-1, libgtk2.0-dev, libgtkgl2.0-dev, libglade2-dev, liblablgl-ocaml-dev (>= 0.99-3)

This, with the Provides, Conflicts, Recomend and Suggest, is enough for
handling dependencies, and much more easier to understand and work with
than the XML horror you where suggesting.

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

Friendly,

Sven Luther
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners