On Tue, Feb 25, 2003 at 11:59:18PM +0100, Sven Luther wrote:
> > Look how much perl modules is debianized and how much ocaml modules is.
> 
> This is because there are much more debian maintainers who package perl
> stuff, than debian maintainers who package ocaml stuff. Also mostly we
> prefer to package stuff we use, as it is much easier to do high quality
> packages in these cases. And help is always welcome. I guess it is the
> same for PLD too.

But the perl packages are *much* easier to package. And that's because
they're standardized.

> > CPAN modules are standardized. That's the main advantage of them. We need
> > this kind of stuff for ocaml. 
> > 
> > What we should standardize? IMHO:
> > 
> > 1. Naming conventions. Maybe some guidelines for package names. Anyway
> >    for package foo, version 1.2.3:
> >      - source tarball should be foo-1.2.3.tar.gz
> >      - it should unpack all it's files into foo-1.2.3 directory
> >    (these are good GNU practices anyway)
> 
> Note that debian packaging tools can handle unstandard source tarballs
> without much problems, nice so we don't need to rebuild the tarball,
> which modifies its md5sum.

Yes, sure, rpm can also handle it. But it's still better to have
it in the same place in each package, isn't it?

> > 2. Build procedure. We can either use OCamlMakefile, ocamake, or
> >    some ocaml script. But make it standard for all COAN packages.
> >    Preferably makefiles should be generated or build process should be
> >    performed by a special tool, so it is possible for example to add
> >    DESTDIR support, or shared library support if it's added to ocaml,
> >    in one place instead of hundreds of COAN packages.
> > 
> >    In any event building COAN package should be matter of one command.
> >    And it should be the same command for all COAN packages.
> 
> Yes, DESTDIR support is a pain to add to each ocaml package. I don't
> feel much like forcing a standardized build process though, not everyone
> likes the same, as long as it supports changing the DESTDIR and has a
> fairly easy build process, along the lines of configure, make, make
> install. configure can be by editing a config file or preferably by a
> configure script or a configure makefile target.

Ok, forcing isn't exactly the best way to go. Maybe the best way would
be to prepare example/template package? Then people will probably copy
from it.

> > 3. Installation. IMHO packages should be installed to `ocamlc
> >    -where`/package-name. Installation tool, whatever it is,
> >    should support DESTDIR (i.e. specifying fake root directory).
> 
> Note, that i strongly advocate having two libdir directories, one,
> /usr/lib/ocaml/<version_number>, for packages from the distrib, and the
> second, /usr/local/lib/ocaml/<version_number>, for locally installed
> packages. The first libdir would be given by -distwhere, and the second
> by -where. findlib and such would default to the locale directory, but
> could be overriden by the package maintainer.

Hm... What if ocaml itself is installed in /usr/local? But I believe
you're right here.

> > 4. Documentation. But this should be easy -- just use ocamldoc, 
> >    and maybe some additional files (in pkg-version/doc/).
> > 
> > 5. Enforce META files for findlib?
> >
> > 6. Maybe some metafile describing package and dependencies? 
> >    From which .spec for rpm and makefile rules for debs could 
> >    be generated. Preferably in XML. Example:
> 
> Err, you are speaking about the debian/control files, we don't use
> makefiles for such kind of information, only for building the package.

Yes.

> > <pkg name="mysql" 
> >      version="1.2.3" 
> >      url="http://foobar.com/mysql-ocaml/">
> >   <short>MySQL bindings</short>
> >   <short lang="pl">Wiazania MySQL</short>
> >   <long>
> >     This package provides bindings to MySQL server, blah... blah...
> >     <!-- 10 lines or so -->
> >   </long>
> >   <long lang="de"> .... </long>
> >   <license>BSD-like</license>
> >   <!-- We need to standardize this as well. -->
> >   <category>Bindings/Database</category>
> >   <depends-on>
> >     <!-- packages from COAN: -->
> >     <coan-pkg name="foobar" version-not-less-then="1.23"/>
> >     <!-- maybe name="foobar >= 1.23" will be better? -->
> >     <coan-pkg name="foobar-baz" version-equal="1.23"/>
> >     <!-- system packages: -->
> >     <system-pkg name="ocaml" version-not-less-then="3.06"/>
> >     <!-- not mysql-devel or mysql-dev, just mainstream name -->
> >     <system-pkg name="MySQL" version-not-less-then="1.2.3"/>
> >   </depends-on>
> > </pkg>
> 
> Well, first, i personnally don't like CML, but seriously, don't you
> think that this format is a bit oververbose and incomprehensible for
> just plain dependencies ?

The nice thing about XML is that there are already tools to parse and
transform it. And that's why I don't believe it's an overkill.

> For debian, we just have dependencies and build dependencies. Each of
> those are listed in a field of the debian/control file, some of which
> are dynamically generated at build time. As an example, lablgtk has the
> following :
> 
> (* for the source package *)
> Build-Depends: debhelper (>> 3.0.0), ocaml-3.06-1, libncurses5-dev, xlibs|xlib6g, debhelper, libgtk2.0-dev, libgtkgl2.0-dev, libglade2-dev, liblablgl-ocaml-dev (>= 0.99-3), librsvg2-dev
> ...
> 
> (* for the runtime package *)
> Depends: ocaml-base-3.06-1,  ${shlibs:Depends}
> ...
> (* for the developpment package *)
> Depends: liblablgtk2-ocaml (= ${Source-Version}), ocaml-3.06-1, libgtk2.0-dev, libgtkgl2.0-dev, libglade2-dev, liblablgl-ocaml-dev (>= 0.99-3)

This is the same as in rpm. But this kind of stuff can be generated from
<depends-on /> I gave above (with little human intervention).

> This, with the Provides, Conflicts, Recomend and Suggest, is enough for
> handling dependencies, and much more easier to understand and work with
> than the XML horror you where suggesting.

> >     <coan-pkg name="foobar" version-not-less-then="1.23"/>

---> Depends: foobar (>= 1.23)

> >     <system-pkg name="MySQL" version-not-less-then="1.2.3"/>

---> Build-Depends: mysql-dev (>= 1.2.3)

This is simple, you just need to look at it for a moment.

-- 
: Michal Moskal ::::: malekith/at/pld-linux.org :  GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::: Wroclaw University, CS Dept :  {E-,w}-- {b++,e}>+++ h

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners