[opam-devel] opam binary snapshot
Sylvain Le Gall
sylvain+ocaml at le-gall.net
Thu Oct 31 13:36:32 GMT 2013
2013/10/31 Anil Madhavapeddy <anil at recoil.org>:
> On 15 Oct 2013, at 00:36, Mika Illouz <mika at illouz.net> wrote:
>> Our current system involves packaging up OCaml stuff as
>> debian packages, and distributing them to ubuntu clients in binary
>> form via a internal debian repo. This gets the ocaml dependencies
>> necessary to build stuff, even to those don't develop in ocaml, with
>> minimal cognitive overload.
<as usual, shameless plug>Most of my libraries use _oasis and I use
oasis2debian to create and distribute Debian packages which really
look like what you get from standard Debian distribution (I am a
former Debian Developer). I think it is a great idea but it has some
shortcomings, including the need to rebuild everything if a deps in
the chain change... but we can discuss this elsewhere.</as usual,
>> Some of my colleagues think that distributing ocaml dependencies in
>> binary form is ultimately more stable. I am wondering whether I can
>> satisfy them, with a solution that somehow exports as binary snapshot
>> of everything under ~/.opam/4.01/ . One idea is to define a debian
>> package for a blessed ~/.opam/4.01/ , and export it via our internal
>> debian repo. Another idea is just export it to clients via rsync, or
>> some other shared global storage.
> [Ccing opam-devel and also Citrix/Rackspace folk, as this came up
> last week in XenSummit).
> In general, I'd like to figure out how to use OPAM to build RPMs and
> Debs just as easily as it can currently do ocamlfind installations.
> In the short-term, I suspect that if you use a system compiler and
> have enough external dependency information in the OPAM repository,
> we could get away with quite a lot by tarring up the .opam directory.
In fact, I also need a tool like this. I was planning to create an
opam2debian that given a set of packages build a big .deb containing
the compiled OCaml code. I am extremly interested to see if something
exists or to participate in coding it (well I'll do it at one point
but won't complain if someone else does it).
But rather than targeting ~/.opam/4.01 it should be installed in
/opt/opam/4.01, I think there is an OPAMROOT variable somewhere. This
way you can get stable filename in your target (because "~" will
expand differently and some OCaml packages use hardcoded path).
Another interesting challenge is to "fake" the filesystem to make OPAM
and the underlying build system install in
$CURDIR/debian/tmp/opt/opam/4.01, while it thinks it install in
/opt/opam/4.01 (system call diversion may work for most installer).
And also fake ACL for that (but we have fakeroot in this case).
Concerning just taring the .opam, you will have anyway problem with
"~" path expansion + missing deps...
If someone want this program, count me in.
> This has also been a frequent request for teaching purposes, so I'd
> like to experiment with version controlling .opam -- this would just
> require hooks when adding/creating files in the subdirectory hierarchy,
> although it would probably be too slow to shell out every time
> (Thomas' cagit OCaml library may come in useful here).
> Dave/Jon/John, any thoughts on this?
More information about the opam-devel