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
next prev parent 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).