Ocaml ports needs love

[Gabor Pali]

On Thu, Aug 1, 2013 at 10:20 PM, Michael <michipili at gmail.com> wrote:
> from the standpoint of a system administrator having two sets A and
> B of software packages managed by two different tools has a lot of
> drawbacks:

I am fully aware of all the issues you have summarized as I have been
maintaining the Haskell Cabal ports for the last 4-5 years, whose
number in the ports tree slowly exceeds 400 these days :-)

> I picture myself something like
> having an opam.bsd.mk makefile delegating all its work to opam, as in:
>
> do-build:
>     ${CD} ${WRKSRC} opam build ${OPAMPACKAGENAME}

OPAM only has an "install" subcommand which is the build and the
install phase together.  On the other hand, I do not think that OPAM
could work with standalone packages.  It has to have a package index
where it stores all the metadata (i.e. the OPAM package and compiler
descriptions), but packages are still served via the regular OCaml
build solutions, such as OASIS.

As I wrote in my previous mail, OPAM is much like the reincarnation of
the ports tree itself in OCaml land.

> — OPAM manages its “own file hierarchy” and does not install binaries
> and so on at the regular places (I only glimpsed at this, tough).

It puts binaries under its own ".opam" state directory, depending on
which compiler is used.  Note that because OPAM supports using
multiple different OCaml compilers (and switching between them),
personally I see it hard (if not impossible) to integrate with the
practices of the FreeBSD ports.

>     A quick fix for this could be to have a dedicated installation, say
> something like “OPAMROOT=/usr/local/opam” and adding the relevant
> locations to the path (binaries and dll).

OPAM uses the "config env" subcommand to set all the relevant
environment variables for the currently used compiler toolchain, like
it sets the PATH each time, so the corresponding binaries are used to
build the packages.  Bringing this to the level of the system (i.e.
prepend the OPAM directories to the system-level PATH value) might not
be the best solution.

Note that what FreeBSD ports would require is actually the build
"recipe", most of the other things can be then derived.  So, we could
utilize the OPAM package descriptions to generate FreeBSD ports but
not OPAM itself.

> — OPAM does not distinguish between build and install while FreeBSD
> ports do.

Yes, it does not, see above.

>     I think this is mostly a security issue: building does not require
> elevated privileges, only installing does. To support this separation,
> we would need to tweak OPAM for FreeBSD.

OPAM is indeed missing the separate "install" target in its package
description.  I have not managed yet to learn why this design choice
was made...

> — We need to generate pkg-plist or extract an installation script or any
> similar information from an OPAM package.
>
> — We need to extract tarball location, dependancy information and
> descriptions from OPAM packages.

Been there, done that.  For the Haskell Cabal ports, I have such a
tool, called hsporter [1] (which can also help with updating, by the
way).

> BTW I have a port for ocaml-4.00.1 (PR ports/173364) which still has a
> small issue — because other ports install docs in
> '/usr/local/share/doc/ocaml' , the directory will not  be cleanly
> removed.

What ports?  Other OCam ports (that depend on lang/ocaml)?  Have you
tried @dirrmtry instead of @dirrm in the pkg-plist?


[1] https://github.com/freebsd-haskell/hsporter