[aur-general] Ocaml Packages

[Xyne]

Thomas S Hatch wrote:

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

Sorry, I should have been clearer in my previous message. A package should
*never* appear in both the depends and the makedepends array. If a package is
required both to build and to run it, it should appear in, and only in, the
depends array. If it's only needed to build the package but not to run it then
it should be in the makedepends array.

I have edited the Wiki page to remove "ocaml" from the makedepends array.

Perhaps it should be made clearer on the wiki page that the example PKGBUILD is
only for OCaml libraries.


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

*nods*

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

*nods again*

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

If the bytecode were an application then I would not include the "ocaml-"
prefix in the name, assuming that no libraries were included.

The "ocaml-" prefix should indicate that the package is for working with OCaml,
i.e. that it provides something which is only useful to an OCaml coder, which
will normally be a library, or something else that you can import in your code.

If the package provides a an executable that the user can use without caring
about the language behind it, then it should not contain the prefix. That
applies to bytecode as well, as the user need not be concerned with the
underlying code.

For packages that mix both libraries and applications, it can go either way. I
would opt for using the prefix in that case to indicate the presence of
libraries, but I know that there are some Haskell packages which use the
binary's name without the "haskell-" prefix despite the inclusion of libraries.

There's probably a better, pithier way to express this, but it eludes me right
now.