On Tue, Jan 4, 2011 at 9:46 AM, Xyne <[email protected]> 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
