caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Michal Moskal <malekith@pld-linux.org>
To: Sven Luther <luther@dpt-info.u-strasbg.fr>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Alternative proposal: COAN
Date: Wed, 26 Feb 2003 10:47:47 +0100	[thread overview]
Message-ID: <20030226094747.GA5164@roke.freak> (raw)
In-Reply-To: <20030225225918.GA13944@iliana>

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


  reply	other threads:[~2003-02-26  9:48 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-24 16:54 Benjamin C. Pierce
2003-02-24 18:24 ` Chris Hecker
2003-02-24 20:17 ` Francois Rouaix
2003-02-24 20:28   ` Basile STARYNKEVITCH
2003-02-24 21:03   ` Brian Hurt
2003-02-24 21:10     ` Brian Hurt
2003-02-24 21:22       ` Benjamin C. Pierce
2003-02-25 10:54     ` roberto
2003-02-25 13:20       ` Sven Luther
2003-02-25 13:36         ` roberto
2003-02-25 16:07           ` Sven Luther
2003-02-25 14:17       ` MikhailFedotov
2003-02-25 17:15       ` Eric C. Cooper
2003-02-25 21:48         ` Michal Moskal
2003-02-25 22:14           ` Lauri Alanko
2003-02-26 14:06             ` Sven Luther
2003-02-27  8:05             ` Blair Zajac
2003-02-27  8:29             ` Xavier Leroy
2003-02-23 16:51               ` Chet Murthy
2003-02-27 15:39               ` [Caml-list] hierarchical modules John Carr
2003-03-01 18:09                 ` [Caml-list] " Xavier Leroy
2003-03-01 18:18                   ` Michal Moskal
2003-03-02 15:58                     ` Xavier Leroy
2003-02-25 22:59           ` [Caml-list] Alternative proposal: COAN Sven Luther
2003-02-26  9:47             ` Michal Moskal [this message]
2003-02-26 10:11               ` Sven Luther
2003-02-26 10:26                 ` Michal Moskal
2003-02-26 11:53                   ` Sven Luther
2003-02-26 10:35                 ` Olivier Andrieu
2003-02-26 12:03                   ` Sven Luther
2003-02-27  3:19                   ` Nicolas Cannasse
2003-02-23 15:05                     ` Chet Murthy
2003-02-27  4:54                       ` Nicolas Cannasse
2003-02-23 16:13                         ` Chet Murthy
2003-02-27  9:20                           ` Sven Luther
2003-02-27 10:39                         ` Damien Doligez
2003-02-28  9:20       ` Jacques Garrigue
2003-02-28 10:53         ` Sven Luther
2003-02-28 12:28         ` Jean-Christophe Filliatre
2003-02-28 13:08           ` Markus Mottl
2003-02-28 13:27             ` Sven Luther
2003-02-28 14:05               ` Jean-Christophe Filliatre
2003-02-28 14:43                 ` Sven Luther
2003-02-28 15:58                   ` Benjamin C. Pierce
2003-03-01 18:03                 ` Michal Moskal
2003-03-01  8:14         ` Blair Zajac
2003-03-02 18:21         ` Xavier Leroy
2003-03-02 20:09           ` Sven Luther
2003-03-02 21:38           ` Doug Bagley
2003-03-03  2:39         ` Nicolas Cannasse
2003-03-03  9:07           ` Sven Luther
2003-03-03  9:24             ` Nicolas Cannasse
2003-03-03  9:37               ` Sven Luther
2003-02-26 18:42 Jeff Bowden

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030226094747.GA5164@roke.freak \
    --to=malekith@pld-linux.org \
    --cc=caml-list@inria.fr \
    --cc=luther@dpt-info.u-strasbg.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).