Re: [Caml-list] Re: GODI

[Gerd Stolpmann <info@gerd-stolpmann.de>]

Am Mit, 2004-04-14 um 04.52 schrieb Jacques GARRIGUE:
> From: Christophe TROESTLER <Christophe.Troestler@umh.ac.be>
> > 
> > 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