[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GODI and Debian?



On Tue, Mar 14, 2006 at 01:40:06PM +1100, skaller wrote:
> On Mon, 2006-03-13 at 20:19 -0500, Eric Cooper wrote:
> > On Mon, Mar 13, 2006 at 12:58:15PM +0100, Matthieu Dubuget wrote:
> > > What can I do, as a Debian and Ocaml user, if I want to work with recent
> > > stuff on my Debian stable, without breaking everything?
> > 
> > Stefano Zacchiroli built Sarge backports of the 3.09.0 OCaml release:
> >     http://lists.debian.org/debian-ocaml-maint/2005/11/msg00301.html
> > Not the most recent stuff, but close.
> > 
> > > An idea that comes to mind would be to use Godi, instead or beneath
> > > debian packages. Is it possible? And what would be the interaction
> > > between the two systems? Especially regarding standard (I mean not
> > > specific to ocam) packages like gtk?
> > 
> > I can't answer this, since I prefer to have all my packages handled in
> > the "One True Debian Way" :-)
> 
> GODI installs into /usr/local or wherever you tell it.
> 
> Therefore GODI will not break Debian: another user not
> putting /usr/local/* into PATH, LD_LIBRARY_PATH, etc etc,
> just won't see your Debian stuff.
> 
> The reverse problem is slightly harder, since Ocaml is
> sloppily built from packaging viewpoint. Typically when

could you give some details of that claim of sloppiness ? 

> using a foreign Ocaml, it will correctly find its own
> pervasives and libraries.

The right way to do this is for godi to follow the debian way naturally. The
debian infrastructure is almost ready for multiple incarnations of ocaml, and
we could imagine a ocaml-built-from-cvs set of packages loaded to
experimental, altough the need to rebuild those libraries make experimental
not the best place for this.

The ocaml libraries go into /usr/lib/ocaml/<version>, and it is thus easily
possible to generate 100% orthogonal installations of ocaml on debian for the
libraries, thus taking care of the issues you mention below.

The only real problem are the binaries built, since ocaml has no easy way to
post-pend a version to the binary names, and i am not sure if installing into
/usr/bin/ocaml/<version> and having a massive alternatives setup to link the
right version into /usr/bin is the best possible solution. I don't think
debian has support for alternativing a huge set of binaries, instead of just
one.

> Gerd can tell you more about how findlib handles this.
> 
> The danger comes when Godi packages fail to completely cast
> the Debian install into a shadow .. and you use bits of it by
> mistake.
> 
> This is not nearly as bad on Unix as the situation I have
> to deal with: I have THREE builds of Ocaml on Windows:
> Cygwin, MinGW and MSVC++. Oh, and TWO MSVC++ installations
> (since I run XP64).
> 
> Unfortunately 'the One True Debian Way' is very bad at handling
> Ocaml because every release of the compiler write off all
> generated code: no libraries or bytecode are valid anymore,
> and all must be recompiled.

Well, you know that this is the 'One True Ocaml Way', and highly recomended by
Xavier and the rest of the ocaml team, naturally ? They make no guarantee of
binary compatibility in even stable point releases, and the few times we tried
to do it without this, it broke horribly.

I believe stephano has some ideas on how to auto-detect binary breakage, but
this doesn't solve the real issue.

> GODI on the other hand is designed to handle this properly,
> since it is a SOURCE code based system.

So, godi handles it well because it recompiles everything, and debian doesn't
because you don't want it to recompile everything ?

> NEITHER system automatically recompiles end user code.
> IMHO this is just a bug in Ocaml itself. Felix, Python,
> and most other modern compilation systems automatically
> recompile as required.

It is not a bug in Ocaml, it is a bug in the ocaml team release strategy. But
then some may say it is a feature :)

> There was some talk on debian-ocaml-maint of switching over
> the Ocaml packages to be source code based too.

/me don't remember such talks.

> As mentioned, this will never solve the real problem:
> end user code. (Its just fine for building one or two
> executables/libraries :)

Bah, we have shown that we can handle upgrades and rebuilds in unstable just
fine, and painlessly in a few days/weeks, we need to automate a stable
backport of those, maybe with the alternative buildd infrastructure, or our
own network, as well as provide out-of-cvs built snapshots, maybe for
amd64, i386 and powerpc only though.

We could distribute those from ocaml.debian.org or some other site.

Friendly,

Sven Luther



Reply to: