Ocaml ports needs love

[Gabor Pali]

On Wed, Jul 31, 2013 at 6:38 PM, Michael <michipili at gmail.com> wrote:
> I am curious about how to
> take advantage of OPAM for maintaining OCaml related ports.

Actually, I have been also pondering this for a while already... :-)

> The ideal
> thing would be to have a `opam make-freebsd-port OPAMPACKAGE' subcommand
> that would prepare a nice Makefile, pkg-descr, pkg-plist traid, ready to
> plug in the ports hierarchy.

OPAM looks quite independent and standalone to me: it maintains a
separate directory (called ".opam") for its own files and does
everything (stores tarballs, package database, repository indexes,
state information, installed compilers, and such) there.  I am not
sure we could plug the FreeBSD Port Collection into this ecosystem,
especially that OPAM can remove packages without much fuss (in
contrast to Haskell Cabal, for example).

> There is other language specific package managers—maybe Ruby GEMS and
> Python EGGS, for instance—but I am not aware of how they interact with
> the port system.

Well, up to to my humble knowledge, only the Perl ports implement some
way of integration with the Ports Collection, dubbed "BSDPAN" [1].
For the Haskell Cabal packages, ports are mostly geared towards
providing proper removal, working around large build times, warranting
that the given package builds fine on FreeBSD (especially with the
components of the latest Haskell Platform), and pull in external
dependencies when needed (for bindings, mostly).

For what it is worth, an OPAM repository [2] is much like the ports
tree but without Makefiles and with multiple versions of the same
package and also stores compiler toolchains.  The OPAM package
description supports running on multiple platforms (i.e. can abstract
away from differences like "make" versus "gmake") and allows to add
patches to fix things in the source tarball.  It can also get the
sources directly from a git repository, and can manage overlapping
multiple repositories, can stick packages to certain versions...

In summary, I have a vague feeling that OPAM-managed packages can be
maintained quite well without the help of the FreeBSD Ports
Collection.  We may want to offer pre-built FreeBSD binaries for some
of the leaf ports (e.g. net/unison), though.


[1] http://bit.ly/Jm8v20
[2] https://github.com/OCamlPro/opam-repository