[aur-general] Ocaml Packages

Thomas S Hatch thatch45 at gmail.com
Mon Jan 3 12:18:19 EST 2011

On Mon, Jan 3, 2011 at 4:02 AM, Xyne <xyne at archlinux.ca> wrote:

> Thomas S Hatch wrote:
> > I changed the bytecode changes you made, maybe it will make more sense to
> > you now how ocaml bytecode works.
> Ah, sorry. It's clearer now.
> > I added ocaml back to the makedepends, the ocaml package provides the
> > compiler.
> >
> > OCaml should only be a dependency when the package includes bytecode,
> since
> > ocaml executables are %100 native machine code - this is an error in most
> > OCaml packages (I need to fix a number of mine)
> If the resulting package does not require ocaml then it should not be named
> "ocaml-*". It was my understanding that these packages were OCaml
> libraries,
> i.e. code and/or binaries that should be used within OCaml code.
> Maybe there is a misunderstanding about makedepends vs depends. If a
> package is
> required both to build and to run another package, then it should be
> included
> in the depends array. If the package is only required to build the package
> but
> not to run it then it should be included in the makedepends array.
> So if the resulting packages are stand-alone executables or generic
> libraries
> then they should not be named "ocaml-*" any more than anything written in C
> should be named "c-*". If they are only for use with OCaml then ocaml
> should be
> a dependency and the name should retain the "ocaml-" prefix.
> > Oh, and BTW...
> > How far along should I be before I apply to be a TU? :)
> I'd say you're almost there, but I want to see how this discussion goes
> before
> I say anything more. ;)
> Regards,
> Xyne

Sounds good, in the case of OCaml libs, using the libs will
almost always require the ocaml package, actually, the only cases where it
would not is if the upstream maintainer is not producing bytecode and native
bins, which they always should. So you are most likely correct in that we
should recommended ocaml as a dep and a makedep, and I think we should keep
the naming, not only because of the ocaml dependencies, but also to
distinguish them from the C libs, it would not take long before we started
to see naming conflicts since many libs provide the same functions by the
same names.

So with that said I think I need to clarify that packages like virt-top (
http://aur.archlinux.org/packages.php?ID=44978) which distribute only a
native executable need to NOT be called ocaml-virt-top but since the libs
should distribute code for all three layers and that running said code
requires the ocaml package.

I think that my main problem is that I underestimated the clarity needed on
the documentation, something which should never be done, and that OCaml
builds can be a little more complicated because of the layers.

Also I am trying to bring the conventions inline with the way they were
created by Richard Jones for Red Hat, since they are very clean and Richard
Jones is one of the main OCaml heads.

Does that make sense? I think that you are right on the depends for libs,
and that the naming should stay ocaml-foo for libs. But clarify in the docs
that OCaml applications should be treated like normal applications since
they should not require ocaml.

The viable confusion comes in where an end user application is built in such
a way that it uses the bytecode - I have never seen this, but it is

I will look over the wiki page and look to add more clarity.


More information about the aur-general mailing list