[opam-devel] ows reports
Roberto Di Cosmo
roberto at dicosmo.org
Sun Sep 28 08:20:38 BST 2014
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