From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 DC1117EE51 for ; Thu, 30 May 2013 02:57:40 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of murthy.chet@gmail.com) identity=pra; client-ip=209.85.223.174; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="murthy.chet@gmail.com"; x-sender="murthy.chet@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of murthy.chet@gmail.com designates 209.85.223.174 as permitted sender) identity=mailfrom; client-ip=209.85.223.174; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="murthy.chet@gmail.com"; x-sender="murthy.chet@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ie0-f174.google.com) identity=helo; client-ip=209.85.223.174; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="murthy.chet@gmail.com"; x-sender="postmaster@mail-ie0-f174.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicCAMeiplHRVd+um2dsb2JhbABaiSO8FoEGFg4BAQEBAQYLCwkUKIIjAQEFOgYBGx0BAwwGBRgJFRAPARMRAQUBHIgTAQMPnBCMP4J9hGsKGScNWIgiAQUMjwcHFoNBA4kfikuTLD+EVQ X-IPAS-Result: AicCAMeiplHRVd+um2dsb2JhbABaiSO8FoEGFg4BAQEBAQYLCwkUKIIjAQEFOgYBGx0BAwwGBRgJFRAPARMRAQUBHIgTAQMPnBCMP4J9hGsKGScNWIgiAQUMjwcHFoNBA4kfikuTLD+EVQ X-IronPort-AV: E=Sophos;i="4.87,767,1363129200"; d="scan'208";a="16133246" Received: from mail-ie0-f174.google.com ([209.85.223.174]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 30 May 2013 02:57:40 +0200 Received: by mail-ie0-f174.google.com with SMTP id aq17so3513603iec.19 for ; Wed, 29 May 2013 17:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding:content-type; bh=6k+jffCtrqYYLJ9fWUBfKR6JSuRb5PMjn/uaSO+4QFI=; b=ZeZvlucY/tEiAt2rhIe+NL+ifmX+WiMFvqEndsP7CahJ6g1BH7RdQawn1/TfpiLBDq fBWIaUs3AgDbX9xSLd0JLSr8kolyyOiqZ8rb8YYyF9foSs1Ooesh964VNkdr60BTVfEN 9Fd9FJgfKrSZjkAObIZVOqJNum8qRt3La8Vy1sn6MO4TR328aQGkJwhY9Tc4t/2d+aMs /ETMAYhXNSTXaX8r27SxVDhjdayAfyQmSsaCzkZtdidKASokZsMv2Znn6ioorzNl0tSQ 3Yi8EVRvOfFle+grxhIZULD20X+1oEI2WYS47zCiFsdhyOLvV8iY9uw8o3soyXYAXhbl myXw== X-Received: by 10.50.80.9 with SMTP id n9mr10405233igx.54.1369875458444; Wed, 29 May 2013 17:57:38 -0700 (PDT) Received: from groupon.localnet (adsl-99-175-100-197.dsl.pltn13.sbcglobal.net. [99.175.100.197]) by mx.google.com with ESMTPSA id qn10sm25179872igc.6.2013.05.29.17.57.36 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 May 2013 17:57:37 -0700 (PDT) From: Chet Murthy To: caml-list@inria.fr Cc: Francois Berenger Date: Wed, 29 May 2013 17:57:33 -0700 Message-ID: <1629005.lH05byJ9SH@groupon> User-Agent: KMail/4.8.5 (Linux/3.2.0-38-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <51A6A13F.901@riken.jp> References: <20130523235355.GI6510@siouxsie> <87r4gppk3k.fsf@gmail.com> <51A6A13F.901@riken.jp> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables) 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. 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--