From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id DDF6F7EE6A for ; Fri, 31 May 2013 07:27:31 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of mmatalka@gmail.com) identity=pra; client-ip=209.85.215.182; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="mmatalka@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of mmatalka@gmail.com designates 209.85.215.182 as permitted sender) identity=mailfrom; client-ip=209.85.215.182; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="mmatalka@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ea0-f182.google.com) identity=helo; client-ip=209.85.215.182; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="postmaster@mail-ea0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQAAPwzqFHRVde2k2dsb2JhbABZgmi/OoECFg4BAQEBBwsLCRQEJIIjAQEEAUABGx0BAwELBgULFiUPAQQNAhEBBQEiE4d6AQMJBgGdQYxIgn2EcQoZJw1YiAQBBQyMOIJYB4NXA5VYgWaMHYM+P4Q1 X-IPAS-Result: ArQAAPwzqFHRVde2k2dsb2JhbABZgmi/OoECFg4BAQEBBwsLCRQEJIIjAQEEAUABGx0BAwELBgULFiUPAQQNAhEBBQEiE4d6AQMJBgGdQYxIgn2EcQoZJw1YiAQBBQyMOIJYB4NXA5VYgWaMHYM+P4Q1 X-IronPort-AV: E=Sophos;i="4.87,776,1363129200"; d="scan'208";a="19717934" Received: from mail-ea0-f182.google.com ([209.85.215.182]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 31 May 2013 07:27:31 +0200 Received: by mail-ea0-f182.google.com with SMTP id r16so1125488ead.41 for ; Thu, 30 May 2013 22:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=gesIsR3JWe6nd20ZHNCBtrVKQ/YowVbiCZtcLX0mAP4=; b=PeewLp8+2PltuD5F7EQZH400qqiCciLvvzAtpfG9m0kDgqIZQrZVi/+vPUs0myWt4f oMoezVSyKH7n4z1lTbkfwMjr5hYG3Cq+0mqOgQso9DAfhK0jOTDfTbtB1CCjLOoG+mz/ KuJ/ra7nozYXcrtLE8RTE+N9kGIjvPgt5/S/18+RsqhUGBKeJGXF35TNxVj7xNgn7ixE N+XFEEzyuxiBwcA+1MSNgwqD8UDa53aoff3Iytz2uchuL3f0HGPm7maCoSnyGinrsm6z GJtATRbJ6MHcoifFvSBbVg4/HtD6fY+eUtNy+H54dEm3ylbEwjS87ONsbRVJWe+GMshR lAOg== X-Received: by 10.15.110.197 with SMTP id ch45mr12070763eeb.121.1369978050938; Thu, 30 May 2013 22:27:30 -0700 (PDT) Received: from localhost ([2a01:7e00::f03c:91ff:fe70:2696]) by mx.google.com with ESMTPSA id s43sm64524249eem.13.2013.05.30.22.27.29 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 30 May 2013 22:27:30 -0700 (PDT) From: Malcolm Matalka To: Chet Murthy Cc: Francois Berenger , caml-list References: <20130523235355.GI6510@siouxsie> <1804446.xtBoISCFl2@groupon> <87a9ndovip.fsf@gmail.com> <1552892.QG2BAhEYXC@groupon> Date: Fri, 31 May 2013 05:27:29 +0000 In-Reply-To: <1552892.QG2BAhEYXC@groupon> (Chet Murthy's message of "Thu, 30 May 2013 15:41:54 -0700") Message-ID: <87fvx3oh1a.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables) I think you're missing the point I'm trying to make, or I'm failing to make it: I see no reason why RPM and deb support should be part of Opam. Politically, it makes Opam opinionated about which package systems it prefers, which will mean you can look forward to lots of discussions about why it doesn't support X. The lifecycle arguments you stated are what you find important, but there is no reason to think everyone will find them to be a reasonable argument when all they want is a package for their favorite system. And on a technical level, it's more code to maintain. You say init scripts and configs are not needed by you, but I need them for almost everything I deploy, and that means other people will want support for that as well. It gets complicated. Ideally, when somebody says "Why can't Opam do X" you want to be able to answer "finite amount of time, feel free to add the functionality yourself". But who wants to maintain support in Opam for a bunch of package formats? Removing functionality is hard once it's in there and just because someone contributes code to Opam doesn't mean they will maintain it in the future. Instead, if you allow Opam to export the closure of a package to an external directory structure + some metadata, you can build tools for package the results of Opam builds by a completely orthogonal set of tools. This is effectively what Opam would have to do anyways, so exposing it at this layer makes it easy for me to add my Nix support, you to add your RPM support, and Joe Ubuntu to get his deb support with only one feature addition to Opam which would likely be fairly small and static. /M Chet Murthy writes: > 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--