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 0A81A7EE51 for ; Thu, 30 May 2013 07:11:56 +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.176; 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.176 as permitted sender) identity=mailfrom; client-ip=134.160.33.176; 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.176 as permitted sender) identity=helo; client-ip=134.160.33.176; 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: AuEAAMveplGGoCGwfGdsb2JhbABZgzq/HIJqgRkOAQEJGAU+giMBAQQBOEAGCwsYCRYPCQMCAQIBRRMIAQGIAwa6Go1ugSyDVwOJHY4ehh6OQIFb X-IPAS-Result: AuEAAMveplGGoCGwfGdsb2JhbABZgzq/HIJqgRkOAQEJGAU+giMBAQQBOEAGCwsYCRYPCQMCAQIBRRMIAQGIAwa6Go1ugSyDVwOJHY4ehh6OQIFb X-IronPort-AV: E=Sophos;i="4.87,768,1363129200"; d="scan'208";a="16143923" Received: from postman4.riken.jp (HELO postman.riken.jp) ([134.160.33.176]) by mail3-smtp-sop.national.inria.fr with ESMTP; 30 May 2013 07:11:54 +0200 Received: from postman.riken.jp (postman4.riken.jp [127.0.0.1]) by postman.riken.jp (Postfix) with SMTP id DA33F8280C4 for ; Thu, 30 May 2013 14:11:51 +0900 (JST) Received: from [172.27.98.103] (rikad98.riken.jp [134.160.214.98]) by postman.riken.jp (Postfix) with ESMTPA id 88C6D7F8046 for ; Thu, 30 May 2013 14:11:51 +0900 (JST) Message-ID: <51A6DF97.5010602@riken.jp> Date: Thu, 30 May 2013 14:11:51 +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: caml-list@inria.fr References: <20130523235355.GI6510@siouxsie> <1629005.lH05byJ9SH@groupon> <1804446.xtBoISCFl2@groupon> In-Reply-To: <1804446.xtBoISCFl2@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.50321 Subject: Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables) On 05/30/2013 02:05 PM, Chet Murthy wrote: > > I'm glad we're having this discussion. > > On Thursday, May 30, 2013 06:52:25 AM 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. > > I think this is incorrect. Let me explain. > > (1) when we look at deploying complex collections of code/libs/data > onto multiple machines, usually we assume that the code has already > been built. > > (2) but let's first dispatch the case where the code has -not- been > built. In such a case, I presume you're proposing that the code be > built on each machine, yes? > > (a) this drastically increases the CPU required to perform upgrades > and deploys > > (b) but far, far, far more importantly, it means that on each > machine, a nontrivially complex script runs that builds the actual > installed binaries. If that script contains -any- nondeterminism or > environmental sensitivity, it could produce different results on > different machines. The technical term is "version skew". (c) that's too damn slow > In scale-out systems, this sort of "skew" is absolutely fatal, because > it means that machines/nodes are not a priori interchangeable. And > all of fast-fail fault-tolerance depends on nodes being > interchangeable. > > (3) But let's say that what you really mean is that we should use > tools like puppet/chef/capistrano to copy collections of > binaries/libs/data to target machines and install them. These > scripts/recipes are written by some person. You could have equally > well suggested that that person build Debian packages (or RPMs) of > each OPAM package, writing out all the descriptions and manifests. > > And manually specifying all dependencies and requiremeents. > > Either way, that person is doing a job that OPAM already does a lot > of, and does quite well. Gosh, wouldn't it be nice if OPAM could > generate those RPMs? Well, it's a little more complicated than that, > but really, not much more. The complexity comes in that you -might- > (I'm not saying I have this part figured out yet) want ways to > -generalize- (say) the camlp5 package so that it could be installed on > many different base OPAM installations. > > But setting aside that nice-to-have, imagine that OPAM knew how to > generate RPMs from each package it installed, and from the ocaml+opam > base itself. You combine those, and you can: > > (i) install ocaml, opam, and a bunch of packages > > (ii) push a button, and out come a pile of RPMs, along with > dependencies amongst them (and hopefully on the relevant > environmental RPMs (e.g., libpcre-dev for pcre-ocaml, etc) so that > you can just stuff those RPMs into a YUM repo, go to a second box, > and say > > "yum install opam ocaml pcre-ocaml" > > and get everything slurped down and installed, just as if OPAM had > installed it all, package-by-package. > > --chet-- > > P.S. And this doesn't even get into the unsuitability of chef/puppet > for managing software package installation. There's a reason that no > distro uses such schemes to install the large and complex sets of > packages needed to run amodern Linux box. And why there is no Linux > version of Microsorft's "DLL Hell". Linux distros by and large (and > esp Debian and Ubuntu) have worked hard to make package installation > foolproof -- and chef/puppet etc are anything but. > >