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 KAA04292; Fri, 28 Feb 2003 10:20:43 +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 KAA05089 for ; Fri, 28 Feb 2003 10:20:43 +0100 (MET) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h1S9KfT01127 for ; Fri, 28 Feb 2003 10:20:41 +0100 (MET) Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id SAA00907; Fri, 28 Feb 2003 18:20:16 +0900 (JST) To: roberto@dicosmo.org Cc: caml-list@inria.fr Subject: Re: [Caml-list] Alternative proposal: COAN In-Reply-To: <15963.19322.759255.37091@gargle.gargle.HOWL> References: <02103BF1-4835-11D7-B97A-000A95773ED2@rouaix.org> <15963.19322.759255.37091@gargle.gargle.HOWL> X-Mailer: Mew version 1.94.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20030228182016D.garrigue@kurims.kyoto-u.ac.jp> Date: Fri, 28 Feb 2003 18:20:16 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk The idea to simplify package management in ocaml is certainly a good one. I personally agree very much with Roberto, at least on the issues. From: roberto@dicosmo.org > But it is probably necessary here to clearly separate the different issues... > at first sight, I see: > > - centralized repository: > Issue: we want some central place where to look for Ocaml code > without resorting to google > - easy installation: > Issue: I want to run advi to give flashy LaTeX presentation, and I want t > just get a binary for my nice OS I love so much, without having to > recompile anything > - dependency tracking: > Issue: we would really really like to avoid reading "README"s > to discover the zillion packages on which the next future > generation Ocaml killer application will depend. Just > type "install XYZ" and that's it. His conclusion was that apt-get (or something similar) is the way to go. I agree mostly with this too, but my experience with BSD ports and ocaml upgrading nightmares makes me differ on details. * For me the central repository should not contain the source themselves. This was an error with the CDK: the distribution becomes huge, and it is very difficult for the maintainers to track changes by developpers (who do not necessarily want to work in that repository, for evident practical reasons). Not speaking of licensing problems. With BSD ports, the central repository only contains metadata, that it a directory for each package, with its name, its dependencies, where to find it, how to configure and install it, and eventually some patches to make it fit in the system. The central repository would be a small one containing only metadata, updated often, eventually by authors themselves. Users who want newest stuff update by cvs, others get snapshots. Ideally some snapshots go through testing to become releases. The sources themselves are distributed as tarballs. This may be a good idea to replicate them on a few ftp servers, but there is no reason to make it compulsory. * Easy installation means that you should be able to download, compile and install the desired ocaml program or library in one single command, including all the dependencies. This does not mean that a binary should be available. A binary will only work with a single version of ocaml and all dependencies, which is way too restrictive. Binaries may be provided on a by OS basis, but then it is much more comfortable for users to use the packaging system provided by the OS (tgz on FreeBSD, rpms on redhat, deb on debian, pkg on OSX, ??? on windows...) If the basic framework is right, that work should be easy enough. * Dependency resolution and automatic recompilation/reinstallation is the core of the problem. When you modify an ocaml library, all its dependencies have to be recompiled. You certainly want to automate this, and have some foolproof system to be able to go back to a stable state. This is also an area where a bit of compiler "support" may become necessary. At least, have different library directories for different version of ocaml, ideally some scheme a la OSX to install several versions of the same package in parallel. I personally don't think that standardizing the tools to produce individual package is a useful move. Providing good tools to ease package construction matters, but enforcing them on developpers is counter-productive. What is needed is just the glue to make it uniform from the user point of view. Ocamlfind can probably help there for complex cases, but as simple cases work well enough with ocamlc, I would prefer it to stay optional for end-users (this is certainly OK to rely on it in the implementation of the system). One last comment on Windows. Since most development is taking place on Unix, I think this is reasonnable to make the presence of basic cygwin tools a requirement for compiling packages. The presence of gnu make and some shell commands should be enough for most. Handling of C libraries is more complex, but this must often be handled also at the source level. Thanks for reading my personal opinions. Jacques Garrigue ------------------- 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