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 LAA00536; Wed, 26 Feb 2003 11:12:21 +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 LAA32763 for ; Wed, 26 Feb 2003 11:12:21 +0100 (MET) Received: from mel-rto6.wanadoo.fr (smtp-out-6.wanadoo.fr [193.252.19.25]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h1QACKT24252 for ; Wed, 26 Feb 2003 11:12:20 +0100 (MET) Received: from mel-rta6.wanadoo.fr (193.252.19.26) by mel-rto6.wanadoo.fr (6.7.015) id 3E0C343F026957ED; Wed, 26 Feb 2003 11:11:52 +0100 Received: from iliana (81.49.169.71) by mel-rta6.wanadoo.fr (6.7.015) id 3E26CE2101731980; Wed, 26 Feb 2003 11:11:52 +0100 Received: from luther by iliana with local (Exim 3.36 #1 (Debian)) id 18nyXX-0000iZ-00; Wed, 26 Feb 2003 11:11:51 +0100 Date: Wed, 26 Feb 2003 11:11:50 +0100 To: Michal Moskal Cc: Sven Luther , caml-list@inria.fr Subject: Re: [Caml-list] Alternative proposal: COAN Message-ID: <20030226101150.GA2675@iliana> References: <02103BF1-4835-11D7-B97A-000A95773ED2@rouaix.org> <15963.19322.759255.37091@gargle.gargle.HOWL> <20030225171550.GA5041@stratocaster.home> <20030225214833.GA13418@roke.freak> <20030225225918.GA13944@iliana> <20030226094747.GA5164@roke.freak> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030226094747.GA5164@roke.freak> User-Agent: Mutt/1.5.3i From: Sven Luther Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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/, 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. > > 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. > > > > > > 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 ? > > 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 > 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. > > > > > > ---> Depends: foobar (>= 1.23) > > > > > > ---> 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