🚀 go-pugleaf

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 <murthy.chet@gmail.com> 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--

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