[opam-devel] ows reports
Thomas Gazagnaire
thomas at gazagnaire.org
Sun Sep 28 11:24:07 BST 2014
Hi Roberto,
Thanks for your explanations.
> IMHO, this information is perfectly readable in the current table: if a line is
> fully red, then the answer is no, otherwise it is yes. The advantage of the
> current presentation is that you also immediately see which compiler versions
> are ok.
> If I understand well, you would like to see some kind of information that
> could be used to suggest what could or should be done to "fix" the red cells:
> for example, if a package p has conflicting dependencies, you might want to
> start looking at p, while when a package p depends on a q that is broken,
> you will first look at q, right?
Yes exactly, it is very useful to have a quality metrics for opam-repository (let's say, the number of red cells) but I feel this metrics does not really reflect the way we currently manage the repository and it does not really help when one to improve the metrics results.
For instance, fixing 2.b means adding a new "available" field for the package, which is artificial: if you try to 'opam install' this package, opam will already tell you that the package is not available for your OS or ocaml-version (and I think it is much more precise in the unavailability cause in version 1.2).
Fixing 1.b means finding the right 1.a to fix. So the metrics should be the number of 1.a. in the repo.
> Unfortunately, things are not that simple... if my understanding of how
> opam-repository is maintained today is correct, a package p version v can enter
> the repository at a certain time t only if it is installable. So even in you
> 1.a case, the "blame" for p being uninstallable at some later time t' may still
> go (and will probably go) to some change in some remote dependency of p, and you
> are not better off than in 1.b
We do not track forward-dependencies yet in our testing due to resource constraints, but that was the plan from the beginning. So if a package is installable for a given ocaml version, it should stay installable no matter what in the future. Note that we are currently happy to merge package 2.a which are unavailable on some compiler version (if the package has a field "available") set or 2.b (because it depends on a package which have an "available" field set). Do you think that's a problem?
> So the best we can do today is to provide a detailed explanation of the reasons why
> a package cannot be installed when you click on the red cell: a package may
> depend on a missing package, on a package that is not installable, on packages
> that are in conflict, on version ranges of a package that have no installable
> candidate, and all this, of course, may happen arbitrarily far in the dependency
> graph; even if some effort to display the root causes is made, human
> intervention is needed to decide what to do then.
Yes, and that's already very useful! I just want a way to have only green cells there :-)
> Notice though that the presentation of these explanations is not yet optimal:
> since there are so many versions of packages around in the opam repository,
> providing a compact presentation is not as straghtforward as for the GNU/Linux
> distributions case; quite a bit of work has already gone into this issue
> (many thanks to Louis, btw) and is now being continued by an intern at Irill,
> but the jury is still out on what the right approach really is.
If you need feedback, do not hesitate to ask me (or this list). Would be great to have a tool that the opam-repository maintainers can use efficiently to improve the quality of the repository.
Best,
Thomas
>
> --
> Roberto
>
>> Best,
>> Thomas
>>
>>
>>
>>
>> in the previous message
>>
>> 2014-09-27 20:14 GMT+02:00 Roberto Di Cosmo <roberto at dicosmo.org>:
>>
>> Dear Thomas,
>> I have some difficulty in understanding what exactly you do not
>> understand in the reports present on OWS.
>>
>> Let me try to provide a few hints; a package is reported as "bad"
>> for a given version and a given architecture if there is no way to
>> satisfy its dependencies.
>>
>> This means that there is no way you can install it using opam, and
>> even if the "code" shipped with the package may be perfectly fine,
>> the "package" itself is nevertheless useless.
>>
>> This is why it is often termed "broken", following a terminology
>> that is now standard in the world of package based distribution, as
>> it has been in use for a couple of decades.
>>
>> Why a package is broken, who is responsible of fixing it, is
>> another story: it can be the package maintainer that did not update
>> the dependencies, or the maintainer of a dependency that has
>> wrongly removed it, or the release manager that has not spotted the
>> problem.
>>
>> In the framework of the Mancoosi project we have developed a full
>> suite of tools to help improving the quality of a package based
>> system, and it so happen that all these tools are even written in
>> OCaml.
>>
>> I really do suggest that people on this list take the time and read
>> the short support material that was developed by Zack, Ralf and me
>> for the HATS summer school, and that is available here:
>> http://www.dicosmo.org/Publications/Hats2012.html
>>
>> All the best
>>
>> --
>> Roberto
>>
>>
>> 2014-09-27 19:43 GMT+02:00 Thomas Gazagnaire <thomas at gazagnaire.org
>>> :
>>
>> Hi,
>>
>> I had a quick look at "opam weather services" reports and I am
>> a bit puzzled at how the statistic are computed. It seems that
>> a package is considered as "broken" when one of its dependency
>> cannot be installed. I'm not sure it makes sense: in the case
>> the dependency is not available on a given platform / compiler
>> version, then all the packages which depend upon it are not
>> available as well as "availability" is a transitive relation in
>> opam. These packages are not "broken".
>>
>> Especially, on that page: http://ows.irill.org/table.html a lot
>> of "bad" result are in fact simply a result the package not
>> available for the given compiler version.
>>
>> I'm sure they are packages which are actually broken (ie. there
>> are no version of ocaml where they can be installed) and these
>> should be much more useful to high-light in order than someone
>> try to fix the descriptions (for instance me, when I am bored
>> and have nothing else to do).
>>
>> Best,
>> Thomas
>> _______________________________________________
>> opam-devel mailing list
>> opam-devel at lists.ocaml.org
>> http://lists.ocaml.org/listinfo/opam-devel
>>
>>
>>
>>
>> --
>> Roberto Di Cosmo
>>
>> ------------------------------------------------------------------
>> Professeur En delegation a l'INRIA
>> PPS E-mail: roberto at dicosmo.org
>> Universite Paris Diderot WWW : http://www.dicosmo.org
>> Case 7014 Tel : ++33-(0)1-57 27 92 20
>> 5, Rue Thomas Mann
>> F-75205 Paris Cedex 13 Identica: http://identi.ca/rdicosmo
>> FRANCE. Twitter: http://twitter.com/rdicosmo
>> ------------------------------------------------------------------
>> Attachments:
>> MIME accepted, Word deprecated
>> http://www.gnu.org/philosophy/no-word-attachments.html
>> ------------------------------------------------------------------
>> Office location:
>>
>> Bureau 320 (3rd floor)
>> Batiment Sophie Germain
>> Avenue de France
>> Metro Bibliotheque Francois Mitterrand, ligne 14/RER C
>> -----------------------------------------------------------------
>> GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3
>>
>>
>>
>>
>> --
>> Roberto Di Cosmo
>>
>> ------------------------------------------------------------------
>> Professeur En delegation a l'INRIA
>> PPS E-mail: roberto at dicosmo.org
>> Universite Paris Diderot WWW : http://www.dicosmo.org
>> Case 7014 Tel : ++33-(0)1-57 27 92 20
>> 5, Rue Thomas Mann
>> F-75205 Paris Cedex 13 Identica: http://identi.ca/rdicosmo
>> FRANCE. Twitter: http://twitter.com/rdicosmo
>> ------------------------------------------------------------------
>> Attachments:
>> MIME accepted, Word deprecated
>> http://www.gnu.org/philosophy/no-word-attachments.html
>> ------------------------------------------------------------------
>> Office location:
>>
>> Bureau 320 (3rd floor)
>> Batiment Sophie Germain
>> Avenue de France
>> Metro Bibliotheque Francois Mitterrand, ligne 14/RER C
>> -----------------------------------------------------------------
>> GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3
>>
>>
>>
>>
>
> --
> Roberto Di Cosmo
>
> ------------------------------------------------------------------
> Professeur En delegation a l'INRIA
> PPS E-mail: roberto at dicosmo.org
> Universite Paris Diderot WWW : http://www.dicosmo.org
> Case 7014 Tel : ++33-(0)1-57 27 92 20
> 5, Rue Thomas Mann
> F-75205 Paris Cedex 13 Identica: http://identi.ca/rdicosmo
> FRANCE. Twitter: http://twitter.com/rdicosmo
> ------------------------------------------------------------------
> Attachments:
> MIME accepted, Word deprecated
> http://www.gnu.org/philosophy/no-word-attachments.html
> ------------------------------------------------------------------
> Office location:
>
> Bureau 3020 (3rd floor)
> Batiment Sophie Germain
> Avenue de France
> Metro Bibliotheque Francois Mitterrand, ligne 14/RER C
> -----------------------------------------------------------------
> GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3
More information about the opam-devel
mailing list