OCaml library packaging problem--suggestions needed

mgushee · 2006-04-01 01:55:08

It has come to my attention that there is an inherent difficulty in handling dependencies between OCaml libraries in a binary package system such as ours.

Note that this mainly affects OCaml developers. In general, end users of OCaml-based applications don't need any OCaml libraries at all, since in most cases the applications will be compiled to native code, with all OCaml components statically linked. So, keep that in mind as you consider the following.

The problem is that an OCaml library is only binary-compatible with a single *build* of its dependencies. I.e. if I have libraries A, B, and C such that B depends on A and C depends on A and B, any time I recompile A I *must* recompile B, and any time I recompile A or B, I *must* recompile C (good thing the OCaml compilers are fast, huh?).

For a concrete example, take the Arch packages 'ocaml' and 'lablgtk2'--lablgtk2 being the OCaml wrapper for libgtk2. If the ocaml package gets recompiled for any reason, even if there are no changes in the source code, lablgtk2 must also be recompiled. If this is not done, any project using lablgtk2 will fail to compile (in fact, that's exactly what brought this to my attention--the current lablgtk2 package hasn't been compiled against the current ocaml package).

This is obviously a headache for packagers. If the package 'lablgtk2-2.6.0-1' has a non-versioned dependency on 'ocaml', then it is up to the lablgtk2 maintainer to update the package every time ocaml gets updated--a PITA for the packager, and it will likely get forgotten at times. If, on the other hand, lablgtk2 depended on 'ocaml-3.09.1-1', that would be correct in terms of binary package dependencies, but far too restrictive for anyone who wants to build lablgtk2 from the PKGBUILD--since lablgtk2 is source-compatible not only with any release of OCaml 3.09, but also with OCaml 3.08 and possibly 3.07, too.

A couple of alternatives come to mind:

· Modify ABS to allow runtime dependencies to be more specific than build dependencies. Let's say a field called 'bindepends' were added to the PKGBUILD. You could then do something like:

    bindepends=("ocaml==$CURRENT_PKG", ...
    makedepends=('ocaml', ...

And then through some magic, the $CURRENT_PKG variable would get replaced with whatever package version/release was installed in the build environment.

· Distribute *only* the base OCaml system, and forget about binary packages of any other OCaml libraries. This is not totally unreasonable since, as mentioned above, the users of OCaml libraries are usually developers anyway.

· Have a base ocaml package based on GODI (http://godi.ocaml-programming.de/) instead of the standard distribution. GODI is loosely modeled after CPAN, and has a sophisticated package manager and a slowly growing repository. This way, Arch packages for additional libraries, instead of directly installing the OCaml modules, could invoke the GODI installer. The downside to this is that GODI is a wholly source-based distribution, so installing a package with GODI means compiling it, which conflicts with what people usually expect from binary packages. And, of course, it could considerably slow down a 'routine' system upgrade. But give the niche market for OCaml packages, this might be acceptable.

So, any thoughts on the best approach to this problem? Any alternatives I haven't considered? Thanks in advance for any feedback.

mgushee · 2006-04-01 02:34:39

Just a quick clarification of a point that may not have been entirely clear in my post: the problem is strictly one of dependencies between one OCaml library and another; it doesn't apply to any C-based libraries that the OCaml libraries may depend on. Typically (at least on Linux), an OCaml application that uses a C library will be dynamically linked with it, and is no more version-dependent than anything else linked with that library.

E.g., if I develop a GUI app using LablGTK2, it gets dynamically linked with libgtk-x11-2.0.so and other related libs. To *compile* my app I need to have installed a LablGTK2 package that is compatible with my build of OCaml; once my app is built, however, it is standalone WRT OCaml. It will depend on libgtk2 (and glib, gdk, etc.), but will not be affected by minor upgrades to those libraries.

Arch Linux

#1 2006-04-01 01:55:08

OCaml library packaging problem--suggestions needed

#2 2006-04-01 02:34:39

Re: OCaml library packaging problem--suggestions needed

Board footer