[opam-devel] opam binary snapshot

Anil Madhavapeddy anil at recoil.org
Fri Nov 1 08:26:10 GMT 2013

This is a good question -- I think there's a lot of utility in a
simple binary package mechanism for OPAM.  The problem is that this
is ultimately a deadend for any project that eventually wants to
open-source (such as the Xen work) -- a lot of the work will be
replayed when building Debs and RPMs for upstreaming anyway.

The other thing to remember is how much system-specific policy is
encoded in various upstream OS package managers. That wouldn't be
fun to recreate generally in OPAM, although it could work for
specific distros.  I wonder if your binary package system is really
the right answer for a commercially supported Windows port of OPAM,
rather than the UNIX ports...


On 31 Oct 2013, at 14:01, Fabrice Le Fessant <fabrice.le_fessant at ocamlpro.com> 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 ?
> At OCamlPro, we have already been experimenting with this idea, so if
> it is what you are looking for, and we can gather a set of sponsors to
> fund turning the prototype into stable software, it would be a nice
> addition to OPAM...
> --Fabrice
> On Thu, Oct 31, 2013 at 1:40 PM, Anil Madhavapeddy <anil at recoil.org> wrote:
>> 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.
>>> 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.
>> 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?
>> -anil
>> _______________________________________________
>> opam-devel mailing list
>> opam-devel at lists.ocaml.org
>> http://lists.ocaml.org/listinfo/opam-devel
> -- 
> Fabrice LE FESSANT
> Scientific Advisor, OCamlPro SAS

More information about the opam-devel mailing list