[opam-devel] opam binary snapshot

Sylvain Le Gall sylvain+ocaml at le-gall.net
Tue Nov 5 01:34:39 GMT 2013

Made some progress on opam2debian: I can generate an installable
package, but ocamlfind need some tuning.

You can checkout the github repository:

You will need to install jingoo as well:

Build opam2debian (and install if you want).

$ ../opam2debian.byte create --name opam2debian-test --verbose --build ounit
... [do a lot of thing, including building the binary package]

$ sudo dpkg -i opam2debian-test_20131105_amd64.deb
# The package is 3.1MB but uses system compiler...

$ env OPAMROOT=/opt/opam2debian/opam2debian-test/ opam list -i
base-bigarray   base  Bigarray library distributed with the OCaml compiler
base-threads    base  Threads library distributed with the OCaml compiler
base-unix       base  Unix library distributed with the OCaml compiler
ocamlfind      1.4.0  A library manager for OCaml
ounit          2.0.0  Unit testing framework ...

# and to prove that I am not cheating.
$ opam list -i
Please run 'opam init' first to initialize the state of OPAM.
'opam list -i' failed.

However I have still this issue:
$ /opt/opam2debian/opam2debian-test/system/bin/ocamlfind list
ocamlfind: Config file not found - neither
nor the directory

I need to figure out why and what I am missing here.


2013/11/4 Sylvain Le Gall <sylvain+ocaml at le-gall.net>:
> 2013/11/4 Mika Illouz <mika at illouz.net>:
>> Hi Everyone,
>> Thanks for the discussion. A tool which publishes an existing OPAM
>> installation as one or more deb's would match our internal needs
>> rather nicely.  Since my knowlege of OPAM's and Debian's package
>> systems is superficial, I don't understand two technical questions:
>> First, how would the tool infer the dependencies to non-opam packages
>> managed by debian?  (Sylvain says this is easy).
> For runtime dependencies (once the package is built), this is rather
> easy. Debian maintainer script detect exec and library and compute
> dependencies from there. I.e:
> $ ldd /usr/bin/man
>         linux-vdso.so.1 =>  (0x00007fff7a9ff000)
>         libmandb-2.6.2.so => /usr/lib/man-db/libmandb-2.6.2.so
>         libman-2.6.2.so => /usr/lib/man-db/libman-2.6.2.so
>         libgdbm.so.3 => /usr/lib/x86_64-linux-gnu/libgdbm.so.3
>         libpipeline.so.1 => /usr/lib/x86_64-linux-gnu/libpipeline.so.1
>         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
>         libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1
>         /lib64/ld-linux-x86-64.so.2
> Then you just have to ask the packaging system which package provide
> the given libraries:
> $  dpkg -S /usr/lib/x86_64-linux-gnu/libgdbm.so.3
> libgdbm3:amd64: /usr/lib/x86_64-linux-gnu/libgdbm.so.3
> Et voila ! You know that /usr/bin/man depends on the package libgdbm3.
> For OCaml binary:
> - native: works just as a normal binary:
> $ ldd /usr/bin/unison-gtk
>         linux-vdso.so.1 =>  (0x00007fff8efa6000)
>         libgtk-x11-2.0.so.0 =>  ...
> - bytecode: the binary itself doesn't have dependencies, but if it has
> a non-OCaml dependencies, there will be a .so somewhere (stub
> libraries) that will create the link.
> All above is what is needed to compute runtime dependencies. We have
> additional tools to compute dependencies of .cmo/.cmx/.cmxa/.cma but
> this doesn't apply to what I want to do sine the generated package
> should be self-contained (except in the case of compiler=system, but I
> have injected a the usual Debian OCaml Maintainer trick for that by
> depending on ocaml-nox-${F:OCamlABI}).
> Now there are remaining problem:
> - build dependencies cannot be guessed
> - runtime dependencies on executable cannot be guessed (e.g. if you
> use Sys.command "patch" it is hard to guess that you depend on patch)
> I plan to solve this through a small DB, should be enough to start.
>>  Second, how would it
>> expose individual OPAM packages as debian packages?  On one extreme,
>> the entire OPAM installation is packaged as one deb; on the other, a
>> debian package is created from each corresponding OPAM package.
> I plan to create on big source package containing a checkout of the
> repository and a script that allow to build the package on specific
> architecture. Basically you get:
> opam2debian-le-gall.net-4.01_20131104.tar.gz
> opam2debian-le-gall.net-4.01_20131104.dsc
> This is the bare minimum to have a source package, then on each arch
> (i386, amd64, armhf) you extract the source package and build it. This
> will generate:
> opam2debian-le-gall.net_20131104_amd64.deb (or _i386 or _armhf).
> opam2debian-le-gall.net_20131104_amd64.changes (or _i386 or _armhf).
> You just have to sign the changes file before uploading.
> Note that given the way I built it, you ALSO get a snapshot of the
> OPAM repository inside the archive! Which means that if you want to
> build additional packages, you will use the snapshot from inside the
> debian package you are building!
> I am trying to see how I will translate the copyright to be nice to
> upstream contributor (this is a pretty big issue, trying to figure a
> solution).
>> While this approach calls for a tool separate from OPAM itself, it
>> preserves OPAM's OS/distribution-neutrality.
>> On Oct 31 2013, Fabrice Le Fessant wrote:
>>> Is it important to target RPMs and DEBs, or would it be enough to
>>> have binary packages _inside_ opam ? i.e. "opam install MYPACKAGE"
>>> would install binary versions instead of source versions of
>>> MYPACKAGE and all its dependencies ?
>> Fabrice: I'm not sure I understand what your are proposing.  One of my
>> goals is to be able to distribute deb's derived from OPAM, but without
>> requiring OPAM.
>> On Oct 31 2013, Sylvain le Gall wrote:
>>> Maybe you are talking about directly generating a binary .deb ? (like
>>> directly an ar archive, but that is super tricky to do)
>> Sylvain:  I think that's what I want ...
>>> I could not resist the temptation to start the project:
>>> https://github.com/gildor478/opam2debian
>> Cool!
>> thanks
>> mika illouz

More information about the opam-devel mailing list