[aur-general] Ocaml Packages

[Thomas S Hatch]

On Tue, Jan 4, 2011 at 9:46 AM, Xyne <xyne at archlinux.ca> wrote:

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

That clears a few things up, I have some packages to fix :)
I have been looking at the depends and the makdedepends in the redhat
Requires and BuildRequires sense! Sometimes I forget that simplicity rules!
(I don't know if I mentioned this but I used to work for Red Hat, some
axioms die hard :) )

As for your explanation of the naming I completely agree, although I would
sway towards naming a package only by it's name and not by ocaml-foo if the
package provides an application that just happens to include libs. Thats
like saying that every python package should be named python-foo, unless the
package consists of just a script.

I will chew on this info and figure out a better way to express this info on
the wiki.

-Tom