Re: [Caml-list] Alternative proposal: COAN

[Sven Luther <luther@dpt-info.u-strasbg.fr>]

On Wed, Feb 26, 2003 at 10:47:47AM +0100, Michal Moskal wrote:
> 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.

Well, i guess well written ocaml packages are quite easy to package
also, it is just the ones that have broken or short-sighted build
process, like those thinking everyone support the native-code compiler,
or that forget about the DESTDIR. 

Mostly my build recomendations would be :

  o support a DESTDIR to install in another directory than you built for.

  o support to build either the bytecode or the native code compiler,
    having an option to rename both versions as the same name. I build
    packages containing both sometimes.

I don't think really more is needed, apart from the standard libdir
detection or such.

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

There is already example OCAMLMKFILE, but i think some people (like
myself) don't like it and prefer to use their own makefiles. Also some
people may want to use findlib and other not. There is no problem with
that, as long as the resulting build system meets certain criterias,
like the above.

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

Well, that is the users problem. In debian, and i guess in other
distribs also, the filesystem is mostly reserved for the package
manager, and therefor cannot be used by the user. The only exception are
/usr/local and the user home directory, /home/jo_user. And /etc where
the user may modify configuration files.

Therefor every user installed module should either stay in his
homedirectory or go into /usr/local if it is to be installed
system-wide. Therefor ocaml should be able to look into at least 3
different places for its modules, which is not possible now.

So, until ocaml get OCAMLPATH support, there is nothing we can do about
it.

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

Well, but at the expense of human readability, which is i think a loss.
Anyway, i think debian packages will not be automatized, or at least the
maintainer will need to check if the package is not doing some strange
things or such. So, something easy to cut&paste will have my preference
over the nightmarish stuff you proposed. Also remember that packages may
have different names on different distribs or something such.

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

Sure, just not easily with vi.

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

Unless the distib has foobar1 and foobar1.2 available, unless they
changed foobar into libfoo-dev or other something such. There is human
intervention needed to check this, so at least make it readable.

Friendly,

Sven Luther
-------------------
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