Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Shared run-time DLLs for commerce
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Richard Jones <rich@a...>
Subject: Re: [Caml-list] Shared run-time DLLs for commerce
On Tue, Jan 08, 2008 at 07:42:21PM +0000, Jon Harrop wrote:
> On Tuesday 08 January 2008 19:39:04 Christophe TROESTLER wrote:
> > On Mon, 7 Jan 2008 22:17:31 +0100, Stefano Zacchiroli wrote:
> > > FWIW it would also save a lot of time and effort for maintainers of
> > > OCaml-related software in (binary-based) GNU/Linux distributions, as
> > > Debian and Red Hat.
> >
> > On Tue, 8 Jan 2008 16:03:51 +0000, Richard Jones wrote:
> > > This is certainly true.  The single, brittle digest is a real problem
> > > for Red Hat.  It should be at least possible to add additional values
> > > and types without that causing incompatibility.
> >
> > Why don't you guys discuss exactly what kind of robustness you need
> > and introduce a feature wish in the bug tracker?
> Of course, the package maintainers could always simply remove the
> digest test from their own OCaml package and hope for the best. ;-)

The problem, though, is that you _can't_ remove that test from the

OCaml modules in Fedora have deps like this:

$ rpm -q --requires ocaml-libvirt
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(VersionedDependencies) <= 3.0.3-1  
ocaml(Buffer) = f6cef633ea14963b84b79c4095c63dc3
ocaml(Callback) = e5ca1fb5990fac2b7b17cbb1712cffe2
ocaml(Char) = e98bc9c9e918a84b3c1a5a122d42fac1
ocaml(Pervasives) = 8ba3d1faa24d659525c9025f41fd0c57
ocaml(String) = 2c162ab314b2f0a2cfd22d471b2e21ab
ocaml(runtime) = 3.10.0

These deps do ensure that you can't install the wrong RPM without
forcing it, but don't allow us any sort of backwards compatibility.
When Ocaml 3.10.1 comes out, we'll need to recompile everything.  More
critically our customers will have to recompile all of their code too.

A single critical library somewhere can have the same effect.

OCaml in RHEL/EPEL has to stick with the same libraries, even if they
have bugs, even if they have _security_ bugs (probably, but not hit
that one yet thankfully).

This is quite different from the way that RHEL provides guaranteed
binary compatibility for 7 years, with continual upgrades and
backporting along the way.


[1] Well, OK I guess we could patch it out, but that'd be a really
stupid idea.

Richard Jones
Red Hat