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

[Chet Murthy <murthy.chet@gmail.com>]

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