Re: GODI and Debian?
On Tue, Mar 14, 2006 at 06:28:22PM +1100, skaller wrote:
> 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.
This seems vague, and should not be so. I doubt this is true given how ocaml
works.
> Second, it doesn't always find the correct linker and
> assembler.
This may be the cause of the above, not sure.
> Third: I think, but am not sure on this one:
> bytecode doesn't always find the correct runtime.
normal, ocaml embedds /usr/bin/ocamlrun, which know to find the real runtime
libs, and the cause of the problem with the above.
i guess it is simply the godi stuff which may be broken, or you not specifying
the right path, or specifying the /usr/local path after the /usr/bin one.
> The first two points are a serious pain for me
> on Windows where I have THREE distinct ocaml installations
> (Cygwin, MinGW, and Win32 native).
So, how is it done there ?
> 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.
Well, i think your installs are seriously messed up, which is why you have
those problems, check your path and which binaries are being used.
> 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.
Well, this seems normal indeed. If you are calling the native debian ocaml
tools when trying to build godi, or a blend of the two, then no surprise the
result is broken and unpredictable.
> 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.
Ok.
> 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
it can even now be automated to a point :)
> keeping packages synchronised this doesn't help
> end users to do the same.
Not at this time indeed.
> > 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.
No, if the binaries issues are solved, the libs should be all right.
> 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?
Nope, the compiler is builtin.
> > 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.
No, the point of alternatives, is that the packager provide a default, which
the user can override.
> 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.
until ocaml breaks api as well as abi.
> > > 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??
Which is why debian knows to track those things and rebuilds them for them.
The only problem is that we are not today able to allow the installation of
two sets of packages simultaneously, but having them both available should be
no major problem if only one is installed.
> > > 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.
Don't build them from tarballs, or rebuild them ? Contribute to the debian
ocaml packaging tool so they are included in debian, and end user will not
have such problems ?
> 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
let's burn all heretics :)
> available package! And it is broken for AMD64. no matter
> how fast debian ocaml maint team is .. Debian itself is
> definitely NOT :)
Bah, freeze is scheduled for july and release for december, stephano has
stable backport of 3.09.0 for you to use, what else do you want ?
Friendly,
Sven Luther
Reply to: