[opam-devel] [NEW] OCaml oasis and Janestreet Core and Async

[Anil Madhavapeddy]

On 10 Oct 2014, at 11:48, Kenneth Westerback <kwesterback at gmail.com> wrote:

> On 10 October 2014 14:46, Kenneth Westerback <kwesterback at gmail.com> wrote:
>> On 10 October 2014 13:03, Christopher Zimmermann <christopher at gmerlin.de> wrote:
>>> Hi,
>>> 
>>> attached you find many new OCaml ports. Mainly the following two and
>>> their dependencies:
>>> 
>>> * Oasis (an OCaml project build and metadata tool) used by many of our
>>>  OCaml ports.
>>> 
>>> * Janestreet Core standard library overlay and Janestreet Async
>>> 
>>> Oasis depends on devel/janestreet/ocaml-type_conv while most of
>>> janestreet stuff uses oasis. If this is too much, I could leave the rest
>>> of janestreet for now and only import ocaml-type_conv.
>>> 
>>> Since I'm currently waiting for the release of OPAM 1.2
>>> (https://github.com/jasperla/openbsd-wip/tree/master/sysutils/opam),
>>> which can be used to install all those libraries and binaries, I'm
>>> wondering whether it still makes any sense to maintain those ports in
>>> our ports tree. The same applies to other ports already in our tree
>>> like devel/{utop,ocaml-lambda-term,ocaml-lwt} ...). Opinions? OKs?
>>> 
>>> 
>>> Christopher
>> 
>> Personally I would prefer to use opam over ports. The only reason I
>> can see for maintaining ports is if they are needed to build other
>> ocaml ports (mldonkey?) in the tree. That's my 0.05C (Canada has
>> eliminated the penny).
>> 
>> .... Ken
> 
> I guess we would also need a port when upstream needs patches to
> compile on OpenBSD. Hopefully a rare situation going forward.

I'm happy to merge OpenBSD-specific fixes into OPAM -- it's possible to
add OS-specific selectors in the patches field to not affect other OSes.

However, it is very convenient to be able to depend on a binary
installation of OCaml libraries for end-user applications, particularly
given the strict versioning requirements.  The OpenBSD port is also
higher quality when it comes to architecture portability, since it
separates out bytecode vs native code vs native dynlinking architectures.

There is enough metadata available in an OPAM package to generate a
snapshot of OpenBSD ports from a given package set.  I'm not suggesting
we automatically import the results into OpenBSD, but it would really
help keep the ports tree in sync with the latest versions of libraries.
The metadata needed for this is roughly:

- build instructions -- present in OPAM, but they do not separate out
  fake installation and native code at the moment.  This could be added
  to OPAM fairly easily.

- external dependencies -- OPAM has a 'depexts' field where OS packages
  can be specified.  This is a free-form field, so it could be a precise
  pkgspec for the OpenBSD entry.

- categories and homepages -- these can be lifted straight out of the 
  OPAM spec, and tags can be used to map OpenBSD-specific information.

More broadly though, does any other language-specific packaging system
do this at the moment, or all ports maintained manually? 

-anil