[opam-devel] ows reports

Anil Madhavapeddy anil at recoil.org
Tue Sep 30 18:06:37 BST 2014

On 30 Sep 2014, at 17:19, Thomas Gazagnaire <thomas at gazagnaire.org> wrote:

>> 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.
> vs.
> $ 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.

Why don't we just do that with a mechanized pass of the repository to rewrite packages to add the `available` field when missing?  It's also clearer to the user if there's an available field in the immediate package description, instead of having to invoke `opam` to perform the dependency resolution.  That wouldn't require any changes to ows either.

Although, now that I think about it more, one big downside is that the `available` field may become out-of-date when a *new* version of a dependency is added, such as this one today in Batteries [1] that tweaks `available` versions.  We would have to then adjust all the upstream `available` packages also, which seems rather error prone.

[1] https://github.com/ocaml/opam-repository/pull/2779

I'm CCing Damien Doligez, since he's been fixing a huge number of these issues in the OPAM repository recently, and is cooking up some tools to help with OCaml release engineering.  Roberto, is the source (even if it's not very clean) to ows available for us to experiment locally?  I'd prefer not to duplicate efforts between Damien, us and you if possible, but I also don't want to cause you extra work if OWS isn't easily re-installable.


More information about the opam-devel mailing list