[opam-devel] opam binary snapshot

[Sylvain Le Gall]

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