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 3C2AA7EE6A for ; Fri, 31 May 2013 00:42:02 +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.160.42; 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.160.42 as permitted sender) identity=mailfrom; client-ip=209.85.160.42; 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-pb0-f42.google.com) identity=helo; client-ip=209.85.160.42; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="murthy.chet@gmail.com"; x-sender="postmaster@mail-pb0-f42.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMBAM3Up1HRVaAqk2dsb2JhbABaiSO5cn0WDgEBAQEHCwsJFAQkgiQBBToGARsdAQMMBgUOExUQDwETEQEFARwGiA0BAw+dSYxIgn2EdQoZJw1Yh3QBBQyPEAeDVwOJIJ15P4RV X-IPAS-Result: AtMBAM3Up1HRVaAqk2dsb2JhbABaiSO5cn0WDgEBAQEHCwsJFAQkgiQBBToGARsdAQMMBgUOExUQDwETEQEFARwGiA0BAw+dSYxIgn2EdQoZJw1Yh3QBBQyPEAeDVwOJIJ15P4RV X-IronPort-AV: E=Sophos;i="4.87,773,1363129200"; d="scan'208";a="16261857" Received: from mail-pb0-f42.google.com ([209.85.160.42]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 31 May 2013 00:42:01 +0200 Received: by mail-pb0-f42.google.com with SMTP id uo1so1148706pbc.29 for ; Thu, 30 May 2013 15:41:59 -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=pmQDWl/7NCU2Jq9iq1kLYFcOonZgybaHlpWlaeE5TRQ=; b=b8eZwk8iyBDDxTmN6JHucfc/ZhWvxBIaX7wu04MYJVwkE8nK8TW9Kc6LoqjlvWwP8d Czy6YNPAO+tvSt7OKe/ghQxq5q+eTDBhWwpAZrKq+/nXJBE8zU4r0mtBSFFluENK/hAn 3Zoqipye7T5c9MAoY+wn0muJI8AD8oFyOUvpX8a/A64bRcAJnZcuy6ibuL+5xIOeZkAa 54ZQemCoKJc/wdQk22qFyW6EFuF6qz6rSPzWQCeJqusNdukSAj3xWxzmHd2yjBk4eDgA kfx9zghkHDqdygTzWQc076/WUx8JshMa5IO4oXqJ/SE7HUs/PINi4m7BWJ4MzJphfgyx g6lQ== X-Received: by 10.66.241.71 with SMTP id wg7mr10566780pac.12.1369953719617; Thu, 30 May 2013 15:41:59 -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 10sm43645760pbr.45.2013.05.30.15.41.57 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 May 2013 15:41:58 -0700 (PDT) From: Chet Murthy To: Malcolm Matalka Cc: Francois Berenger , caml-list Date: Thu, 30 May 2013 15:41:54 -0700 Message-ID: <1552892.QG2BAhEYXC@groupon> User-Agent: KMail/4.8.5 (Linux/3.2.0-38-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <87a9ndovip.fsf@gmail.com> References: <20130523235355.GI6510@siouxsie> <1804446.xtBoISCFl2@groupon> <87a9ndovip.fsf@gmail.com> 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'll answer in-line. (1) why not Nix? easy. take a look at the Debian Packaging Manual. It describes a -detailed- set of requirements for Debian packages' pre/post scripts. There's a -lifecycle- there that is a big part of why you can run a Debian machine for 12 years across 3-4 releases, and never reinstall. That doesn't happen on RPM-based systems, because there's no such lifecycle. [It's similar to why Macs, even before OSX, were so much more reliable than Win32. Even though -Windows- had a primitive (and weak) sort of virtual memory and the Mac didn't even use the MMU. Software discipline was what made it better. And the same is true of Debian packages. There's no equivalent of "puiparts" in the RPM world. You should look at piuparts.] (2) [what about all the other stuff? init scripts, configs? dependencies?] Why, -precisely-. In most cases, there's no need to init/config. But dependencies are critical. Opam knows some of them already. Since opam does the build, it could discover a lot more, cheaply. The alternative is to make the programmer write it all up, and get it wrong. (3) [just export the files and let the user package it up] You mentioned "fpm". I use "checkinstall" in a similar way. Neither has any idea what the dependencies are, and no way of figuring it out. And yet, dependency-management is -why- you want a package-manager. So you don't get half-installed packages with missing prereqs. (4) [on a production machine, you'd never have libraries -- just executables, right?] Unless that production machine is used to build ocaml programs? Or run (say) hadoop-like jobs that need to compile (SQL-like) queries into binary code? Besides, even if you have only a few machines, it's still wiser to generate a binary package and then install that -- because then you can -reproduce- that configuration on another machine. I work with a (C++) product that has a pile of 20+ prereqs. Each is basically built and installed into a directory on NFS, and all the devs mount that NFS server. When a fix needs to be applied, it gets applied to that shared NFS. Heaven protect us against somebody making an error in applying a fix to a prereq. If this were done using binary packages, every dev would locally install the various prereqs as DEBs or RPMs. Fixes would be updates to those RPMs. It would be possible to update, rollback, to find out what exact versions of the prereqs were used in building some snapshot of the product, etc. In short, commercial software development is -also- a production environment. (5) [Am I asking for OPAM to know how to "deploy" to farms of servers?] Most assuredly not. I'm just asking for OPAM to know how to build DEBs and RPMs that can be installed to a later (suitably similar/identical) OPAM instance to reproduce the configuration of the instance where the packages were built. The transport and application of the packages MUST be someone else's responsibility. --chet--