From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id XAA21315; Tue, 25 Feb 2003 23:59:50 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id XAA21616 for ; Tue, 25 Feb 2003 23:59:48 +0100 (MET) Received: from mel-rto3.wanadoo.fr (smtp-out-3.wanadoo.fr [193.252.19.233]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h1PMxmT00008 for ; Tue, 25 Feb 2003 23:59:48 +0100 (MET) Received: from mel-rta10.wanadoo.fr (193.252.19.193) by mel-rto3.wanadoo.fr (6.7.015) id 3E0C33B50266C27A; Tue, 25 Feb 2003 23:59:20 +0100 Received: from iliana (81.50.248.12) by mel-rta10.wanadoo.fr (6.7.015) id 3E26DAA6016DEF91; Tue, 25 Feb 2003 23:59:20 +0100 Received: from luther by iliana with local (Exim 3.36 #1 (Debian)) id 18no2g-0002CC-00; Tue, 25 Feb 2003 23:59:18 +0100 Date: Tue, 25 Feb 2003 23:59:18 +0100 To: Michal Moskal Cc: caml-list@inria.fr Subject: Re: [Caml-list] Alternative proposal: COAN Message-ID: <20030225225918.GA13944@iliana> References: <02103BF1-4835-11D7-B97A-000A95773ED2@rouaix.org> <15963.19322.759255.37091@gargle.gargle.HOWL> <20030225171550.GA5041@stratocaster.home> <20030225214833.GA13418@roke.freak> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030225214833.GA13418@roke.freak> User-Agent: Mutt/1.5.3i From: Sven Luther Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Tue, Feb 25, 2003 at 10:48:33PM +0100, Michal Moskal wrote: > 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. 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. > 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. > 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. > 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/, for packages from the distrib, and the second, /usr/local/lib/ocaml/, 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. > 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. > version="1.2.3" > url="http://foobar.com/mysql-ocaml/"> > MySQL bindings > Wiazania MySQL > > This package provides bindings to MySQL server, blah... blah... > > > .... > BSD-like > > Bindings/Database > > > > > > > > > > > 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 ? 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, 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. > 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 :-) 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