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 89BB37EE51 for ; Thu, 30 May 2013 07:05:25 +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.182; 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.182 as permitted sender) identity=mailfrom; client-ip=209.85.223.182; 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-f182.google.com) identity=helo; client-ip=209.85.223.182; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="murthy.chet@gmail.com"; x-sender="postmaster@mail-ie0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuACALLdplHRVd+2lWdsb2JhbABZiSO8HYEDFg4BAQEBBw0JCRIqgiMBAQU6BgEbHQEDDAYFDgoJFRAPARMRAQUBHAaIDQEDD5wcjD+CfYRtChknDViIIgEFDI1igSUHg1cDiR+ddz+EVYFK X-IPAS-Result: AuACALLdplHRVd+2lWdsb2JhbABZiSO8HYEDFg4BAQEBBw0JCRIqgiMBAQU6BgEbHQEDDAYFDgoJFRAPARMRAQUBHAaIDQEDD5wcjD+CfYRtChknDViIIgEFDI1igSUHg1cDiR+ddz+EVYFK X-IronPort-AV: E=Sophos;i="4.87,768,1363129200"; d="scan'208";a="16143512" Received: from mail-ie0-f182.google.com ([209.85.223.182]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 30 May 2013 07:05:24 +0200 Received: by mail-ie0-f182.google.com with SMTP id a14so27050091iee.41 for ; Wed, 29 May 2013 22:05:22 -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=c8uK4miZaRHJBJeUcEh9rmhEQPh0r/+COZiAVOMLAc0=; b=BHSLLZp2knBPY4en5SUw5IPElUqw2+5TP4P8oZ2f6g08TQuCmmamTyphXbR7ErMD/l i1XmxYVlU+qel5b3qMFFgwVwC0MXDXu9IikSRnhJPPwzsoduct04u2W2YBpajOrFA8Eb p+auERhZjQQ9QvhGhcuyhAJe1PQ39j6X494YUpSdvLJWmVQI6zHwSo7xnfp0TY6GegAC IZZrSPhxWqzH4XqU/2bU312WZwItFSQaVmW3SHTWveZGaZtElAOA4r5V1K0Z+1zBMrjy eusQp0PqzjTMUZBchItLM3QA8lzSSx3rtLUNFfweayhgWF5DyiuaGq/EHF8d92l3vpv9 Pkfw== X-Received: by 10.50.11.72 with SMTP id o8mr2955303igb.44.1369890322815; Wed, 29 May 2013 22:05:22 -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 k10sm22506653ige.0.2013.05.29.22.05.20 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 May 2013 22:05:22 -0700 (PDT) From: Chet Murthy To: Malcolm Matalka Cc: Francois Berenger , caml-list Date: Wed, 29 May 2013 22:05:15 -0700 Message-ID: <1804446.xtBoISCFl2@groupon> User-Agent: KMail/4.8.5 (Linux/3.2.0-38-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: References: <20130523235355.GI6510@siouxsie> <1629005.lH05byJ9SH@groupon> 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) 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". 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.