Bug 487080 - Review Request: jocaml - Join-calculus extension of Objective Caml
Review Request: jocaml - Join-calculus extension of Objective Caml
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-02-23 20:38 EST by Michel Alexandre Salim
Modified: 2010-11-11 11:45 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-11-11 11:45:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michel Alexandre Salim 2009-02-23 20:38:02 EST
Spec URL: http://salimma.fedorapeople.org/specs/funpl/jocaml.spec
SRPM URL: http://salimma.fedorapeople.org/specs/funpl/jocaml-3.11.0-1.fc10.src.rpm
JoCaml is a extension of Objective Caml for concurrent and
distributed programming, based upon the join-calculus.
Comment 1 Michel Alexandre Salim 2009-02-23 20:43:53 EST
Packager notes:
- see http://yquem.inria.fr/pipermail/jocaml-list/2009-February/000105.html
  for packaging discussions with upstream

- using standard find-provides/find-requires rather than Ocaml's, because the
  latter outputs internal modules that mostly duplicate Ocaml's, which could
  potentially mean that installing an Ocaml library would pull in Jocaml instead
  of Ocaml.

- This JoCaml is configured with a companion Ocaml, meaning it fallbacks to using
  the Ocaml-provided library if a particular JoCaml library is not present. Thus
  most of the standard library have been stripped out (again, to avoid dependency
  confusion). Because JoCaml skips from 3.10.0 to 3.11.0, that means this package
  has to be tested using Rawhide's Ocaml.

- This is tested with the JoCaml ray tracer:

  Upstream promises to provide a test suite that can be used to verify that our
  stripped JoCaml is still functional; will test against it when it arrives.
Comment 2 Richard W.M. Jones 2009-02-24 05:11:19 EST
Copy of an email I sent on this subject to Michel

On Mon, Feb 23, 2009 at 08:50:05AM -0500, Michel Salim wrote:
> Almost ready with the review request, but there are some things I need
> to resolve regarding OCaml find-provides and find-requires first:
> http://yquem.inria.fr/pipermail/jocaml-list/2009-February/000107.html
> - JoCaml provides an almost-identical set of base libraries to OCaml,
> and so if I use ocaml-find-provides.sh and ocaml-find-requires.sh, it
> might erroneously cause JoCaml to be pulled in when a user installs an
> add-on OCaml library on a system without an installed ocaml.

The situation sounds similar to the OCaml cross-compiler that we ship


In that case the solution is to (a) have a separate library directory
and (b) have a modified ocaml-find-provides/ocaml-find-requires which
uses the alternate library directory and makes "ocaml(jocaml,Module) = HASH"
dependencies.  Step (b) is not actually implemented right now.

In the case of the cross-compiler, we choose between them using
findlib and an environment variable:


> - When asking upstream about the modules that have different hashes,
> it was revealed that some of the dependencies discovered by
> ocaml-find-provides.sh might be internal modules, rather than exported
> libraries. I'm attaching the diff between the sorted lists provided by
> ocaml and jocaml:

Yes, the scripts are a bit hit-and-miss, because the program we use
(ocamlobjinfo) doesn't quite have the necessary output to do
dependency analysis properly.  To get around this we hard-code a few
modules to ignore, and generally it works well, but possibly there are
still a few bugs in this area.
Comment 3 Jason Tibbitts 2009-08-03 21:34:18 EDT
So what's the status here?  The last comment makes it seem as if there are problems with this package, but I don't know enough about ocaml to know for sure.  Is there something that needs to be fixed before this package can be reviewed?
Comment 4 Richard W.M. Jones 2009-08-05 03:34:27 EDT
I don't have much time to look at these packages
(and bug 460894) but I'm more than happy to leave
them open.  If I catch Michel on IRC I'll remind him.
Comment 5 Jason Tibbitts 2010-11-02 17:28:44 EDT
After being marked "not ready" for well over a year now, can we just close this out?
Comment 6 Richard W.M. Jones 2010-11-02 17:35:08 EDT
I guess so, Michel?
Comment 7 Michel Alexandre Salim 2010-11-11 11:45:37 EST
Busy with some other packages; I'll create a new request when I have time to fix the packaging.

Note You need to log in before you can comment on or make changes to this bug.