Re: GODI and Debian?
On Tue, 2006-03-14 at 07:27 +0100, Sven Luther wrote:
> > 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 ?
Sure. First, it doesn't always find the correct pervasives
nor other parts of the library.
Second, it doesn't always find the correct linker and
assembler.
Third: I think, but am not sure on this one:
bytecode doesn't always find the correct runtime.
The first two points are a serious pain for me
on Windows where I have THREE distinct ocaml installations
(Cygwin, MinGW, and Win32 native).
The documentation actually says that 'OCAMLLIB' environment
variable is not required on XP and that is plain wrong.
It doesn't work properly UNLESS that variable is correctly set.
All these issues are compounded when searching for user
libraries (as opposed to system installed ones).
The top level and camlp4 have similar problems,
only even worse.
BTW: please note I said Ocaml is sloppily built
from a packaging viewpoint, I did NOT say the
Debian packaging was sloppy!! What I meant
was as above -- Ocaml tools don't behave in a nice
modular fashion and plug together properly.
There is of course also the problem that you need
to rebuild sources when Ocaml is upgraded, which is
a pain for end users and debian maintainers.
Even though the latter can do lots of hard work
keeping packages synchronised this doesn't help
end users to do the same.
> The right way to do this is for godi to follow the debian way naturally.
Lol :)
> 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.
Agree, this is the right way.
> 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.
Yes, this is nasty. I have the same problem with Felix so I'll
be quite interested in what you come up with.
If you don't fork the binaries, then the libraries mentioned
above only need dynamic load parts (bytecode, shared libs),
since native code links aren't possible against old versions
once the compiler is upgraded.
This makes sense (many run packages, but only one dev package).
But I don't know about the top level .. it compiles to bytecode
too .. does it exec ocamlc to do that?
> I don't think
> debian has support for alternativing a huge set of binaries, instead of just
> one.
That's true. But it is up to the packagers to decide when one
binary conflicts with and upgrades another, or is a distinct
package.
With GODI this isn't such an issue because it is SOURCE
based: stuff is just source, so changing Ocaml version
doesn't change these source libraries -- they need to
be rebuilt, but the packages themselves don't change.
> > 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.
yes, I know that's what happens. The problem is: how do users keep
track of all the sources that need to be rebuilt??
People who use Ocaml are programmers, so they have ocaml codes
which are NOT packaged by Debian or GODI and therefore cannot
benefit from an external package manager to stay up to date.
This is back to old problems with Unix/C codes from 2 decades ago.
The only real solution is for OCAML to automatically rebuild
out of date things on an 'on demand' basis.
Or at least have a stronger 'findlib' kind of program to do
that for you.
> I believe stephano has some ideas on how to auto-detect binary breakage, but
> this doesn't solve the real issue.
No, but it is a good step in the direction of automatically
rebuilding when necessary .. if you can identify when 'necessary'
actually is :)
> > 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,
Indeed, but what do I as an end user do? I click the upgrade
button in Synaptic and now 30 libraries I build from tarballs
are unusable.
With Python what happens? Nothing. It just works.
Felix also compiles binaries .. but it is designed to
work like Python. You execute source code .. the binaries
are just cached to save compile times. Its then up to
the implementor of the Felix system (me:) to make sure
the caches are invalidated when necessary.
Also point out .. I still have Ubuntu 3.08.3 as my latest
available package! And it is broken for AMD64. no matter
how fast debian ocaml maint team is .. Debian itself is
definitely NOT :)
--
John Skaller <skaller at users dot sourceforge dot net>
Async PL, Realtime software consultants
Checkout Felix: http://felix.sourceforge.net
Reply to: