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 OAA01702; Wed, 14 Apr 2004 14:45:58 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id OAA00897 for ; Wed, 14 Apr 2004 14:45:56 +0200 (MET DST) Received: from mail.npc.de (fw.npc.de [62.225.140.214]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i3ECkujq026928 for ; Wed, 14 Apr 2004 14:46:56 +0200 Received: from styx.ffm.npc.de (lion.npc.de [192.168.129.1]) by mail.npc.de (Postfix) with ESMTP id 1FCCD12C9; Wed, 14 Apr 2004 14:45:54 +0200 (CEST) Received: from hera.ffm.npc.de (hera.ffm.npc.de [192.168.130.8]) by styx.ffm.npc.de (Postfix STYX NPC GmbH) with ESMTP id 95545C437; Wed, 14 Apr 2004 14:45:50 +0200 (CEST) Received: from ares.ffm.npc.de (ares.ffm.npc.de [192.168.130.32]) by hera.ffm.npc.de (Postfix HERA NPC GmbH) with ESMTP id 368F2159C9; Wed, 14 Apr 2004 14:45:50 +0200 (CEST) Received: from ares.ffm.npc.de (ares.ffm.npc.de [192.168.130.32]) by ares.ffm.npc.de (Postfix ARES NPC GmbH) with ESMTP id 93FC4183E; Wed, 14 Apr 2004 14:45:49 +0200 (CEST) Subject: Re: [Caml-list] Re: GODI From: Gerd Stolpmann To: Jacques GARRIGUE Cc: Christophe.Troestler@umh.ac.be, caml-list@inria.fr In-Reply-To: <20040414.115245.31191001.garrigue@kurims.kyoto-u.ac.jp> References: <20040413.200746.94354715.Christophe.Troestler@umh.ac.be> <1081884649.24590.122.camel@ice.gerd-stolpmann.de> <20040413.215709.133591297.Christophe.Troestler@umh.ac.be> <20040414.115245.31191001.garrigue@kurims.kyoto-u.ac.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 14 Apr 2004 14:45:48 +0200 Message-Id: <1081946749.4053.60.camel@ares> Mime-Version: 1.0 X-Miltered: at nez-perce by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 gerd:01 stolpmann:01 2004:99 jacques:01 troestler:01 troestler:01 sven:01 pervasives:01 dpkg:01 basing:01 interfacing:01 interfacing:01 gc's:01 portage:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 325 Am Mit, 2004-04-14 um 04.52 schrieb Jacques GARRIGUE: > From: Christophe TROESTLER > > > > Sven should say better what is possible but my idea is that GODI and > > the Debian package system talk to each other. So there should NOT be > > two Pervasives modules. If the GODI (Debian) package is installed, > > the other Ocaml packages should make use of it. If GODI wants to > > recompile some Debian Package, either (1) delegate the task to the > > Debian package manager (say there is a new version of the package > > available or else use dpkg to download and build from source) or (2) > > consider Debian packages as "on hold" and refuse the GODI operation. > > > > That requires a correspondance between package names on the two sides > > -- thus some dialog with the Debian maintainers -- but it is a good > > idea not to have different names for a given package anyway... > > What you are saying amounts more or less to basing GODI on the debian > packaging system. Interfacing between packaging systems is going to be > just as difficult as interfacing between GC's: almost impossible if > you are not a guru of the two systems. And then why not do it for all > other packaging systems around (rpm, portage, freebsd packages...) > > I think that it would be much more reasonable to have a packaging > system controlling all of ocaml, but only ocaml. This includes > compiling and installing from CVS, because those are the cases when a > recompiling package system is really necessary, and because many > developpers (and potential contributors to GODI) are using CVS > versions of ocaml. They would really benefit from GODi because all the recompilations are handled automatically. My idea to handle this is to substitute the O'Caml core packages by fake packages, only to satisfy the dependencies. But I think this is an option for advanced users only, there are much more things that can go wrong. > The interface to external packaging systems could be just minimal: > external packaging systems handle non-ocaml dependencies, and issue > GODI commands for installing/uninstalling the package. Since GODI may > have to recompile things later, having an external packaging system > trying to track GODI files would be a pain, and probably a useless > one. > > This also makes me think that godi should not handle non-ocaml > packages (like gdbm currently), because this is only going to generate > frictions with other packaging systems. In principle, you are right here. The (few) non-ocaml packages exist for user's convenience, especially on systems where they are not available from the OS. They are optional anyway. > Last, we need support for windows, and for binary packages. I don't > know who is going to do it, but these are requirements to make godi > the standard. The development version works for Cygwin already. Well, I know, this is not Windows, but one faces already typical Windows problems. For example, the locking problem. It is essential for GODI that it can update itself, and unfortunately, Windows does not allow it that a running program replaces itself (unlike Unix). So a workaround was needed. I found it, and guess, who helped? It was /bin/sh and the "exec" call, two imports from the Unix world. Thanks these clever tools one needs not to reboot after updating GODI. This makes me think that a "pure" Windows port would be harder thank we can imagine now. It will be impossible to make it "failsafe": Just cd to a directory managed by GODI, and you break every update (because the directory is locked, and cannot be removed). So I think a source distribution would be too difficult, as it is hard to avoid to get into situations where things fail because of the mentioned reasons, and to recover from such failures in a clean way. In the Windows world, building software is a task that should only happen in controlled environments (without dumb users). So the only alternative is a binary distribution for Windows (it is much easier to recover from failures). > And of course, lots of maintenance needed. I must be using exotic > architectures, but godi never worked properly on any of my machines > (solaris8/x86 and freebsd5.2), at least without lots of tweaking. > Making it work properly on a lot of platforms will require a huge > amount of work, and cannot be handled by a single developper. Well, I invested a lot of time to make it work under Solaris 8/Sparc, and freebsd-4.8. On the latter OS it works nicely out-of-the-box, but I had to disable POSIX threads (not my fault, freebsd's thread library is simply not good enough). Solaris (and probably all commerical Unixes) is a challenge, as the success depends on how properly add-on software (gcc etc.) is installed. My experience is not that a "huge amount of work" is needed to make GODI work on new platforms (one mostly tweaks a number of settings), but a huge amount of patience, simply because building software takes long. > Which creates another problem: GODI is based on C tools and BSD > makefiles. I'm not sure this is the favorite kind of things ocaml > programmers would maintain. It isn't my favourite thing, too, but when you search tools that are powerful and flexible at the same time, the combination of C tools and scripts is simply a good choice. I think for people who only want to create packages, this isn't a burden, because packaging is a quite descriptive task. The maintainance of the GODI core is the problem. There is work underway rewriting some of the tools in O'Caml. For example, there is already a parser for BSD Makefiles. Having our own "make" utility is very interesting, because one can extend the functionality (e.g. macros, or the integration of O'Caml scripts as "make" actions). Of course, these rewrites also simplify the Windows port. > By the way I'm ready to help, if there is some understandable way to > do so. You can join the GODI mailing list (https://gps.dynxs.de/mailman/listinfo). There is now also a bug tracking system (https://gps.dynxs.de/tracker). Gerd -- ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de ------------------------------------------------------------ ------------------- 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