[opam-devel] ows reports

Thomas Gazagnaire thomas at gazagnaire.org
Tue Sep 30 15:34:05 BST 2014


Hi Roberto,

to summarise the discussion so far: in order to remove all the "red"  boxes in ows their are two solutions:

- either we advise people to release packages to not rely on the transitivity of the "available" field and we fix the current "available" metadata to be the transitive closure of what we currently have.

- or we should agree on some display changes on the ows results. I cannot directly contribute to that unfortunately as the source code of ows is not public.

I'm not very keen on doing the first point (because it looks like duplicating meta-data), but if you think your tools cannot be tweaked to do the second point (or if you think that's the wrong approach) I'm fine to do it anyway.  The current metrics measured by ows are wrong regarding the current opam-repository policies, and we should fix that.

Best,
Thomas



On 28 Sep 2014, at 08:20, Roberto Di Cosmo <roberto at dicosmo.org> wrote:

> On Sun, Sep 28, 2014 at 02:29:15AM +0100, Thomas Gazagnaire wrote:
>>    1. Can I install the given package for at least one version of the compiler
> 
> 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 not, is it
>>    because:
>>      a) the package is in "broken" (there is a strong conflict in its
>>    dependencies)
>>      b) the package depends on a "broken" package
>>    2. Can I install the given package with the given compiler version: if not,
>>    is it because:
>>      a) the package is "unavailable" for the given compiler (because
>>    'available' field evaluate to false) or
>>      b) the package depends on an "unavailable" package
>> 
>>    http://ows.irill.org/table.html show an empty square for 2.a but seems to
>>    conflats 1.a, 1.b and 2.b. I think that would be very helpful to highlight
>>    1.a (1.b and 2.b could also be useful to know the root causes of the
>>    problems, ie. either fix 1.a or port 2.a to the given ocaml version).
>> 
> 
> 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?
> 
> 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
> 
> When working in the Debian framework, one can provide more helpful information,
> throught the identification of "outdated" packages (packages that are broken and
> can only be fixed by working on them), but unfortunately the tool that performs
> this analysis is pretty subtle, only works on Debian medatata today, and we
> have no resources to make it work on arbitrary CUDF documents.
> 
> 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.
> 
> As for 2.a and 2.b, the distinction seems also easy to make from the current
> display: an empty cell means the package has a compiler constraint that declares
> it unavailable, while a red cell means the problem is with its dependencies, and
> in that case, you need to click on the cell and investigate what happens.
> 
> 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.
> 
> --
> 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