[opam-devel] ows reports

Thomas Gazagnaire thomas at gazagnaire.org
Tue Sep 30 17:19:36 BST 2014

> In particular, it does not try to solve the difficult issue of finding who is to
> blame for a particular broken package, that's up to the release manager or the
> package maintainers: if a package P marked "available" for 3.12 cannot compile
> because it depends on a package Q that has no version "available" for 3.12,
> it is broken nonetheless, and it must be reported, because a user may try
> to install it and see it fail. I do not understand why you want to change
> this.

Because the kind of errors reported to the user is very different and the way to fix it is different as well.

$ opam install async.108.00.02
The following dependencies couldn't be met:
  - async -> async_core = 108.00.02 -> core < 109.31.00
Your request can't be satisfied:
  - core<109.31.00 is not available because it requires OCaml >= 4.00.1 & < 4.01.0.


$ opam install mirage-www.0.3.0
The following dependencies couldn't be met:
  - mirage-www -> cstruct < 0.6.0
  - mirage-www -> mirage-fs >= 0.4.0 -> cstruct >= 0.6.0 | cstruct >= 0.6.0
Your request can't be satisfied:
  - Conflicting version constraints for cstruct

In the first case, there is nothing to "fix". But to make ows happy we can populate the "available" field of async to get the same message as when trying to install core:

$ opam install core.108.00.02
[ERROR] core.108.00.02 is not available because it requires OCaml < 4.00.1.

This will transform the "red" box in ows into an "empty" box: that's good for the stats, but I'm not sure that's better for an user point-of-view.

In the second case, that's clearly an error if the package that should be fixed (or the package should be removed as there is no valid user configuration where it can be installed). This is a very valuable information which should be high-lighted to the repository (or package) maintainers.

> I'm sure in front of a blackboard things would be much easier to explain, both
> ways, and we will certainly find common grounds then, so let's postpone this
> discussion to the first occasion we can do that

I'm happy to discuss about than in person, although I think that's also good we have that kind of discussion in the open so that other people on that list can follow what's happening and comment if they (don't?) like. But we can maybe organise an opam-devel meeting close to the ocaml consortium meeting (not sure when it is exactly, but can be the same day or the day before/after).


More information about the opam-devel mailing list