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 529E27EE51 for ; Thu, 30 May 2013 07:04:53 +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.162; 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.162 as permitted sender) identity=mailfrom; client-ip=134.160.33.162; 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.162 as permitted sender) identity=helo; client-ip=134.160.33.162; 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: Ag4BALLdplGGoCGifGdsb2JhbABZgzkBr2eSH4EZDgEBCRgFPoIjAQEEATg2CgEFCwsOCgkEEggHCQMCAQIBDyQBEQYNAQUCAQEOh2kDCQYMsQMDCokAjDyCVweDVwOJHYpNgWuBZoEphHWFf4hB X-IPAS-Result: Ag4BALLdplGGoCGifGdsb2JhbABZgzkBr2eSH4EZDgEBCRgFPoIjAQEEATg2CgEFCwsOCgkEEggHCQMCAQIBDyQBEQYNAQUCAQEOh2kDCQYMsQMDCokAjDyCVweDVwOJHYpNgWuBZoEphHWFf4hB X-IronPort-AV: E=Sophos;i="4.87,768,1363129200"; d="scan'208";a="16143453" Received: from postman2.riken.jp (HELO postman.riken.jp) ([134.160.33.162]) by mail3-smtp-sop.national.inria.fr with ESMTP; 30 May 2013 07:04:35 +0200 Received: from postman.riken.jp (postman2.riken.jp [127.0.0.1]) by postman.riken.jp (Postfix) with SMTP id 03B1312604CE; Thu, 30 May 2013 14:04:32 +0900 (JST) Received: from [172.27.98.103] (rikad98.riken.jp [134.160.214.98]) by postman.riken.jp (Postfix) with ESMTPA id 695AB1270051; Thu, 30 May 2013 14:04:31 +0900 (JST) Message-ID: <51A6DDDF.8050500@riken.jp> Date: Thu, 30 May 2013 14:04:31 +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 To: Malcolm Matalka CC: Chet Murthy , caml-list References: <20130523235355.GI6510@siouxsie> <87r4gppk3k.fsf@gmail.com> <51A6A13F.901@riken.jp> <1629005.lH05byJ9SH@groupon> In-Reply-To: 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.45716 Subject: Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables) On 05/30/2013 01:52 PM, Malcolm Matalka wrote: > I think out would be wrong for opam to try to solve this problem. There > are already many tools available for deploying (Ansible, Puppet, Chef, > Fabric, Capistrano). Such a later can be build on top of opam of need be. If OPAM can do it, that would remove a needle from my foot. I am just asking for a cache of the previously built packages. > On May 30, 2013 2: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. > > 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-- > > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs >