Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

Article View: fa.caml

Article #26

#26

From: Chet Murthy
Date: Thu, 30 May 2013 22:42

70 lines
6806 bytes

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--


-- 
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

Technical Details

Message-ID: <fa.0NDyxTvKdCCVuMBP/26F5xOkAng@ifi.uio.no>

Path:

arc1-ca.pugleaf.net!d5ni22751pbl.0!nntp.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!goblin1!goblin.stu.neva.ru!uio.no!nntp.uio.no!.POSTED!not-for-mail

References:

<fa.ygUreM916SCi2HRnlvgczHSDQLY@ifi.uio.no> <fa.dWQhXC5IgbjFHmCE0KHRlxx4o+4@ifi.uio.no> <fa.pekpxcTg2Wh+KXVtLFW4zzxYWLw@ifi.uio.no>

Show Full Headers

Complete Article Headers

X-Google-Thread: c0fe4b917e,943792163446c61a,start
X-Google-Attributes: gidc0fe4b917e,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
X-Received: by 10.68.198.5 with SMTP id iy5mr1755674pbc.3.1369953741488;
        Thu, 30 May 2013 15:42:21 -0700 (PDT)
Path: arc1-ca.pugleaf.net!d5ni22751pbl.0!nntp.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!goblin1!goblin.stu.neva.ru!uio.no!nntp.uio.no!.POSTED!not-for-mail
From: Chet Murthy <murthy.chet@gmail.com>
Newsgroups: fa.caml
Subject: Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's
 variables)
Date: Thu, 30 May 2013 22:42:20 UTC
Organization: Internet mailing list
Lines: 70
Sender: caml-list-request@inria.fr
Message-ID: <fa.0NDyxTvKdCCVuMBP/26F5xOkAng@ifi.uio.no>
References: <fa.ygUreM916SCi2HRnlvgczHSDQLY@ifi.uio.no> <fa.dWQhXC5IgbjFHmCE0KHRlxx4o+4@ifi.uio.no> <fa.pekpxcTg2Wh+KXVtLFW4zzxYWLw@ifi.uio.no>
NNTP-Posting-Host: mail-jess.uio.no
Mime-Version: 1.0
X-Trace: readme.uio.no 1369953740 14833 129.240.7.9 (30 May 2013 22:42:20 GMT)
X-Complaints-To: abuse@uio.no
NNTP-Posting-Date: Thu, 30 May 2013 22:42:20 +0000 (UTC)
User-Agent: KMail/4.8.5 (Linux/3.2.0-38-generic-pae; KDE/4.8.5; i686; ; )
Cc: Francois Berenger <berenger@riken.jp>, caml-list <caml-list@inria.fr>
To: Malcolm Matalka <mmatalka@gmail.com>
X-IronPort-AV: E=Sophos;i="4.87,773,1363129200"; 
   d="scan'208";a="19700477"
X-Original-To: caml-list@sympa.inria.fr
Delivered-To: caml-list@sympa.inria.fr
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"
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)
In-Reply-To: <87a9ndovip.fsf@gmail.com>
X-Sequence: 6851
X-no-archive: yes
List-Id: <caml-list.inria.fr>
List-Archive: <http://sympa.inria.fr/sympa/arc/caml-list>
List-Help: <mailto:sympa_inria@inria.fr?subject=help>
List-Owner: <mailto:caml-list-request@inria.fr>
List-Post: <mailto:caml-list@inria.fr>
List-Subscribe: <mailto:sympa_inria@inria.fr?subject=subscribe%20caml-list>
List-Unsubscribe: <mailto:sympa_inria@inria.fr?subject=unsubscribe%20caml-list>
Original-Date: Thu, 30 May 2013 15:41:54 -0700
Original-Message-Id: <1552892.QG2BAhEYXC@groupon>
Original-References: <20130523235355.GI6510@siouxsie> <1804446.xtBoISCFl2@groupon> <87a9ndovip.fsf@gmail.com>
Bytes: 6500
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit

Reply to Parent Message