From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 5B79D7EE51 for ; Thu, 30 May 2013 03:09:22 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of berenger@riken.jp) identity=pra; client-ip=134.160.33.161; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="berenger@riken.jp"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of berenger@riken.jp designates 134.160.33.161 as permitted sender) identity=mailfrom; client-ip=134.160.33.161; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="berenger@riken.jp"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of postmaster@postman.riken.jp designates 134.160.33.161 as permitted sender) identity=helo; client-ip=134.160.33.161; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="postmaster@postman.riken.jp"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIBACKmplGGoCGhnGdsb2JhbABat0uLBYJqGYEDDgEBAQEBBg0JCRQoghsIAQEEAThAAQULCxgJFg8JAwIBAgFFEwEHAQGFcoIRBroSjxMHglGBBgOJHYpNg1GGHo5A X-IPAS-Result: AoIBACKmplGGoCGhnGdsb2JhbABat0uLBYJqGYEDDgEBAQEBBg0JCRQoghsIAQEEAThAAQULCxgJFg8JAwIBAgFFEwEHAQGFcoIRBroSjxMHglGBBgOJHYpNg1GGHo5A X-IronPort-AV: E=Sophos;i="4.87,767,1363129200"; d="scan'208";a="16133825" Received: from postman1.riken.jp (HELO postman.riken.jp) ([134.160.33.161]) by mail3-smtp-sop.national.inria.fr with ESMTP; 30 May 2013 03:09:20 +0200 Received: from postman.riken.jp (postman1.riken.jp [127.0.0.1]) by postman.riken.jp (Postfix) with SMTP id BBB662588001 for ; Thu, 30 May 2013 10:09:19 +0900 (JST) Received: from [172.27.98.103] (rikad98.riken.jp [134.160.214.98]) by postman.riken.jp (Postfix) with ESMTPA id 76B3A32A0085 for ; Thu, 30 May 2013 10:09:19 +0900 (JST) Message-ID: <51A6A6BF.2000209@riken.jp> Date: Thu, 30 May 2013 10:09:19 +0900 From: Francois Berenger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 CC: caml-list@inria.fr References: <20130523235355.GI6510@siouxsie> <87r4gppk3k.fsf@gmail.com> <51A6A13F.901@riken.jp> <1629005.lH05byJ9SH@groupon> In-Reply-To: <1629005.lH05byJ9SH@groupon> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.5.30.10030 Subject: Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables) On 05/30/2013 09:57 AM, Chet Murthy wrote: > > On Thursday, May 30, 2013 09:45:51 AM Francois Berenger wrote: >> By the way, is there some plan to support binary packages >> at some point in time with OPAM? >> >> I don't mean OCamlPro distributing them but for an OPAM >> user to be able to create them locally. >> >> That would speedup the process of installing software (given they >> have at least been compiled once). > > This. > > OK. A little more. OPAM is already a tremendous improvement. But to > really make it possible to build -systems- in Ocaml, you have to be > able to distribute collections of programs, config, and libraries, > across multiple (admittedly identical) machines. And distribute > updates to same. OPAM is in some ways like BSD ports -- it works > great for maintaining single machines from source-code. And that's why I asked. I think ports are like src-RPMs: they can be turned easily into binary packages. > But what's needed is a way to maintain -many- machines, and to > distribute updates in a granular manner that be -managed- -- rolled > forward, rolled back, with full knowledge of which versions of which > packages are being installed. And everything with -zero- version > skew. So any nondeterminism happened at buiild-time -- by > deploy-time, all machines are getting identical files with identical > timestamps. > > It's a tall order, b/c OPAM will need to figure out how to capture > enough of the environment (in order to check it on the target machine > where a binary is installed) to verify whether it's safe to install > that binary. But boy would it be nice. > > And as a bonus, we could wrapper opam in the debian apparatus (I > think) and get a really nice way to turn opam packages into debian > packages. > > --chet-- >