[opam-devel] opam binary snapshot

[Sylvain Le Gall]

I could not resist the temptation to start the project:
https://github.com/gildor478/opam2debian

I have the answer to all my question and a way to create a debian
archive with an opam installation that use a constant path (no "~" in
path, I use proot to simulate a bind mount in the user space).

Expect some announcement when I will have a first release.

Cheers
Sylvain



2013/10/31 Sylvain Le Gall <sylvain+ocaml at le-gall.net>:
> Hi,
>
> 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,
> shameless plug>
>
>>> 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?
>>
>
>
> Cheers
> Sylvain