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
> violations.
>
> Daniel
>
> 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
>> 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
>> really missing.
>>
>> 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.
>>
>> PaScaL
>>
>> 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
>>> user.
>>>
>>> Here's the part of code that calculates the explanation:
>>> **
>>> *if*(s.getCode() != /UNSATISFIABLE/|| (context != *null*&&
>>> !(context.getProperty(/EXPLANATION/) == *null*||
>>> Boolean./TRUE/.toString().equalsIgnoreCase(context.getProperty(/EXPLANATION/)))))
>>> {
>>> ...
>>>
>>> * return* plan; //that plan
>>> status contains all problematic requirements though all substatus
>>> codes are "Warning"
>>>
>>> }
>>>
>>>
>>> //Extract the explanation
>>>
>>> Set<Explanation> explanation =
>>> projector.getExplanation(sub.newChild(/_ExpandWork_/________/ 4));
>>> //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?
>>>
>>> Thanks,
>>> Katya
>>>
>>> ------------------------------------------------------------------------
>>> *From:* [email protected]
>>> <mailto:[email protected]>
>>> [mailto:[email protected]] *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
>>> be done.
>>>
>>> On 2011-05-12, at 1:40 PM, Todorova, Katya wrote:
>>>
>>>> Hi guys,
>>>>
>>>> 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
>>>> the planner.
>>>>
>>>> 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,
>>>> Katya
>>>>
>>>> _______________________________________________
>>>> p2-dev mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> https://dev.eclipse.org/mailman/listinfo/p2-dev
>>>
>>> <ExplanationHidesRequirementsTest.txt>_______________________________________________
>>> p2-dev mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://dev.eclipse.org/mailman/listinfo/p2-dev
>>
>>
>>
>> _______________________________________________
>> p2-dev mailing list
>> [email protected]
>> https://dev.eclipse.org/mailman/listinfo/p2-dev
>
>
> --
> Daniel Le Berre mailto:[email protected]
> MCF-HDR, CRIL-CNRS UMR 8188, Universite d'Artois
> http://www.cril.univ-artois.fr/~leberre
> _______________________________________________
> p2-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/p2-dev
