[opam-devel] ows reports

[Thomas Gazagnaire]

Hi Louis, welcome back :-)

> If you don't mind me barging in, I think the issue here is mainly one of what is hilighted, and about the use of the red color:
> - if a package can't be installed on any OCaml version, we all agree that's something that needs fixing
> - otherwise, if it only installs on some because of dependencies, we could propagate the 'available' constraint, but as Anil points out we might lose information that may have become useful on dependencies update
> - what actually matters, and was planned from the beginning, but we didn't get to, is actually the _derived function_ of the current table. This is what should be hilighted and reported: if package A could install with version of OCaml X but can't anymore because of some repo change, something went wrong (or we just fixed the repo to reflect reality...)

Agreed. My goal is that it should be possible to make *all* red cells disappear (which is not the case currently), because that's the metrics that people start using when they speak about the quality of opam packages.

Also I've noticed that packages which are not installable because they are not available on all compilers do not appear in the list. I think they should appear there, as it's usually an error in their metadata (see lablgtk-extras 1.2, 1.3 and 1.4, that I've just fixed).

Louis, Instead of the derived function, maybe we can apply to all "broken" packages a post-processing step to classify them using the same function as you wrote to reports conflicts / unavailability errors to the user?

Thomas

> These reports are very useful, but yes, you have to know what they are about and how to read them ; and they use package-management terminology that conflicts with end-user or opam terminology at some points.
>  
> Cheers,
> Louis
>  
>  
> On Tuesday 30 September 2014 17:19:36 Thomas Gazagnaire 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.
> >
> > 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).
> >
> > Best,
> > Thomas
> >
> > _______________________________________________
> > opam-devel mailing list
> > opam-devel at lists.ocaml.org
> > http://lists.ocaml.org/listinfo/opam-devel
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/opam-devel/attachments/20141001/ab27b22f/attachment-0001.html>