|From a user point of view, being able to return all the missing requirements would be very nice since it would allow for a user to remediate to all the problems at once.|
As for the issue with singletons, I think they are less important.
I have opened Bug 345649
On 2011-05-12, at 3:34 PM, Daniel Le Berre wrote:
The resolver computes *one* explanation only, so even if you have
multiple missing requirements, only one will be returned in a minimal
explanation, because it is sufficient to explain the failure.
We might have a trick to manage missing requirements and report all of
them, but we would still have an issue in case of multiple singleton
Le 12/05/2011 21:18, Pascal Rapicault a écrit :
What is returned by the slicer is not an explanation, but just a "bunch
of notes" collected along the way as it was slicing. The information
collected is very vague and here is an example why. I have the following IUs
A requires B [0, 3.0)
B-1 requires C
B-1.1 requires E
B-2 requires D
When the slicer is slicing for A, it will include B-1, B-1.1 and B-2 in
the slice. Now when it slices B-1 it will fail at finding a C and will
create a log. Same will go for B-1.1 with E. When it comes to B-2 it
will find D. In this case, the resolution of A will have a solution. Now
if I take B-2 out of the set of available IUs, then the slicer will
return 2 warnings but really only one of those warnings would have to be
"fixed" for a solution to be found. Of course this is a small example,
if you follow all the possibilities of all the versions you can get a
lot of noise from which it may be hard for you to figure out what is
Computing an explanation is done by the core SAT solver and will sort
through the noise to figure out something that you can act upon.
I will let Daniel explain if more can actually be done.
I have released the test you provided, but it is not enabled as part of
the global test suite.
On 2011-05-12, at 2:45 PM, Todorova, Katya wrote:
The Slicer returns all missing requirements properly but if there's an
attempt to calculate the minimal explanation, some of these
reqirements are cut off and only the first one is returned to the end
Here's the part of code that calculates the explanation:
*if*(s.getCode() != /UNSATISFIABLE/|| (context != *null*&&
!(context.getProperty(/EXPLANATION/) == *null*||
* return* plan; //that plan
status contains all problematic requirements though all substatus
codes are "Warning"
//Extract the explanation
Set<Explanation> explanation =
//here some of missing requirements are removed and the only one
remaining is marked as Error.
Test case attached.
What is the minimal explanation supposed to contain?
[mailto:p2-dev-bounces@xxxxxxxxxxx] *On Behalf Of *Pascal Rapicault
*Sent:* Thursday, May 12, 2011 8:56 PM
*To:* P2 developer discussions
*Subject:* Re: [p2-dev] Planner explanation question
From a quick code inspection to SimplePlanner, setting explanation
to false will completely disable the explanation support (this is
used in the case of the dropins to avoid computing the explanation
since there is no one to read it).
Some of the missing requirements are filtered as part of the
Slicer (but this is expected and filter out the noise), but after
that the explanation is constructed by the solver and it tries to
return the minimal explanation between what you have installed and
what you are trying to install.
However if you have several missing requirements I think it will
stop at the first one. Is that the pb you are seeing?
If you can provide an automated test case, we could see what can
On 2011-05-12, at 1:40 PM, Todorova, Katya wrote:
I came across a strange behavior of p2 planner - it hides
information when trying to resolve an IU and resolution fails
(due to missing requirements for example).
If there are more than one missing requirements the final
explanation (and corresponding MultiStatus) will contain only the
first one found. This default behavior
could be avoided if "org.eclipse.equinox.p2.director.explain"
property is set to "false" in the provisioning context used by
I thought that the explanation is supposed to contain more
details than the "ordinary" status but it turned out it's not the
case and it contains even less. Is that expected?
If yes, any idea why?
Thanks in advance,
p2-dev mailing list
p2-dev mailing list
p2-dev mailing list
Daniel Le Berre mailto:leberre@xxxxxxx
MCF-HDR, CRIL-CNRS UMR 8188, Universite d'Artois http://www.cril.univ-artois.fr/~leberre
p2-dev mailing listp2-dev@xxxxxxxxxxx