Man Linux: Main Page and Category List


       dh_ocaml - calculates OCaml packages dependencies and provides


       dh_ocaml [debhelper options]


       dh_ocaml is a debhelper program that is responsible for filling the
       ${ocaml:Provides} and ${ocaml:Depends} substitutions and adding them to
       substvars files.

       dh_ocaml acts on three kinds of binary packages: those shipping
       development part of OCaml libraries (usually named libXXX-ocaml-dev or
       libXXXX-camlp4-dev), those shipping runtime for OCaml libraires (e.g.
       plugin and shared library, usually named libXXX-ocaml or
       libXXXX-camlp4) and those shipping OCaml bytecode non-custom
       executables (i.e.  executables interpreted by /usr/bin/ocamlrun).

       On specific package the convention is XXX for development and XXX-base
       for runtime (e.g. ocaml-nox and ocaml-base-nox).

       On OCaml library packages dh_ocaml will firstly look at OCaml objects
       shipped by the package. Then, dh_ocaml uses appropriate program on them
       for collecting information about OCaml modules defined and used by
       them. Information about defined units will be used to automatically
       create the OCaml md5sums registry entry for development and runtime
       package, e.g.  /var/lib/ocaml/md5sums/libXXX-ocaml-dev.md5sums.
       Information about imported units will instead be used as keys in the
       OCaml md5sums registry for retrieving dependency information for the
       package. Those information will then be used to fill the
       ${ocaml:Depends} substvars. They will also be used to fill the
       ${ocaml:Provides} substvar which will be replaced by a name of the form
       libXXX-ocaml-dev-NNNN, where NNNN is an checksum computed from the
       interfaces of the modules provided by the library.

       *.cm[aio] are processed by ocamlobjinfo;
       *.cmxa? are processed by ocamldumpapprox;
       *.cmxs are processed by ocamlplugininfo;
       executable are processed by ocamlbyteinfo, if possible.

       Dependencies extracted from the system md5sum registry, dh_ocaml will
       add in ${ocaml:Depends}:

       1.  dependency from libXXX-ocaml-dev to libXXX-ocaml (runtime part of
           the library), if there is a libXXX-ocaml package in debian/control;

       2.  dependency from libXXX-ocaml-dev to the appropriate libYYYY-ocaml-
           dev-NNNN packages;

       3.  dependency from libXXX-ocaml to the appropriate libYYYY-ocaml-NNNN

       4.  dependency from XXXX to the appropriate libYYYY-ocaml-NNNN

       For runtime package ${ocaml:Provides} will be set libXXXX-ocaml-NNNN
       and for development package to libXXX-ocaml-dev-NNNN.

       The same kind of relations are established between libXXXX-camlp4 and
       libXXXX-camlp4-dev packages.


       --checksum str
           Checksum are automatically computed from exported interface by the
           dev/runtime package. This checksum can only show a partial
           information about the interface.  In this case the checksum
           computation can be replaced by another string which gives more
           information about dependencies.

           Typically, ocaml-nox/ocaml-base-nox package doesn’t use a computed
           checksum but the version of OCaml.

       --nodefined-map dev1:unit1,unit2,...
           Ignore some exported unit of package/runtime dev1. This option
           should be used with care. It is a very special case, when one
           library ship a drop-in replacement for another library. Most of the
           time if one library ship the same unit it should be considered as
           an error.

           This option can be repeated as much as needed to define ignore for
           all development packages.

       --runtime-map dev1:runtime1,dev2:runtime2,...
           The association between development part of libraries and their
           runtimes is guessed by dh_ocaml according to the OCaml packaging
           policy. Thus, libXXX-ocaml-dev is the name of the package shipping
           the development part of XXX library while libXXX-ocaml, if any, is
           the name of the package shipping the corresponding runtime.
           libXXXX-camlp4-dev and libXXXX-camlp4 packages are handled the same

           Using --runtime-map you could override the pairs development
           package name, runtime package name. The value passed to
           --runtime-map admits no spaces and must be a comma separated list
           of items. Each item can be a single package name (stating that that
           name corresponds to the development part of a library) or two
           package names separated by a colon (stating that the first
           corresponds to the development part of a library, while the second
           to its accompanying runtime part).

           Every package that doesn’t follow libXXX-ocaml-dev/libXXX-ocaml,
           libXXXX-camlp4-dev/libXXXX-camlp4 or which is not defined in the
           runtime map are considered to be binary package and will be
           searched only for bytecode.


       debian/libXXX-ocaml-dev.olist debian/libXXX-camlp4-dev.olist
           By default, the list of OCaml objects or bytecode binaries shipped
           by your package which should be analyzed for retrieving dependency
           information is guessed by dh_ocaml.

           This file permit to specify a file which lists, one per line, that
           OCaml objects or bytecode binaries. Objects should be in one of the
           format understandable by ocamlobjinfo, ocamldumpapprox,
           ocamlplugininfo or ocamlbyteinfo. Files are considered relative to
           the package build directory.


       Debian policy, version 3.7.2

       OCaml packaging policy, version 1.0.0


       ocamlobjinfo(1), ocamlbyteinfo(1), ocamldumpapprox, ocamlplugininfo,
       debhelper(7), ocaml-md5sums(1)

       This program is a part of debhelper.


       Stefano Zacchiroli <>, Samuel Mimram
       <>, Mehdi Dogguy <>, Sylvain Le Gall