caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Michal Moskal <malekith@pld-linux.org>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Alternative proposal: COAN
Date: Tue, 25 Feb 2003 22:48:33 +0100	[thread overview]
Message-ID: <20030225214833.GA13418@roke.freak> (raw)
In-Reply-To: <20030225171550.GA5041@stratocaster.home>

On Tue, Feb 25, 2003 at 12:15:50PM -0500, Eric C. Cooper wrote:
> I have gotten into the habit of using apt-get for all the Perl modules
> I need to install, rather than going to CPAN.  The Debian maintainers
> have done the hard work of specifying the dependencies, install
> scripts, etc. so that it's easy to install and uninstall them.  I'm
> sure I get only a small subset of CPAN that way, but the quality
> control has been worth it, and I haven't needed anything that wasn't
> already Debianized.
> 
> This is mainly valuable because it is the *same* apt-get tool used for
> everything on the system, not a parallel tool just for Perl.  It makes
> it easier for Perl applications to be mainstream rather than marginal,
> because other packages can easily and robustly specify dependencies on
> the Perl apps.
> 
> For these reasons, a parallel tool just for OCaml would be less useful than
> packaging the relevant libraries as Debian packages (like Sven Luther and
> others have done -- thanks!)  But that doesn't help non-Debian OCaml users.

Look how much perl modules is debianized and how much ocaml modules is.
I can only give figures for PLD (rpms): ocaml - 29, perl - 961. Now this
is not mainly because there is lot more perl modules available. The main
problem is that for average perl package all you need to do to put it
into rpm is:

	%build
	%{__perl} Makefile.PL
	%{__make}

	%install
	rm -rf $RPM_BUILD_ROOT

	%{__make} install DESTDIR=$RPM_BUILD_ROOT

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)

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.

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

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:

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

Note that this does not overlap much with META-files. Intention is that
this meta.xml file should be distributed with sources, not generated
during build. META file might need to be generated (for example to embed
C linker option in it).

Just my 0.02PLN, mainly from packager point of view. In case I'm being
too rpmcentric, Sven please correct me :-)

-- 
: 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-25 21:55 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 [this message]
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
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=20030225214833.GA13418@roke.freak \
    --to=malekith@pld-linux.org \
    --cc=caml-list@inria.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).