Bugzilla – Full Text Bug Listing
| Summary: | [planner] Resolution is not stable | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Pascal Rapicault <pascal> |
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | blocker | ||
| Priority: | P3 | CC: | irbull, john.arthorne, leberre, misha680, tjwatson |
| Version: | 3.6 | ||
| Target Milestone: | 3.6.1 | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 322929, 322971, 323319 | ||
| Attachments: | |||
|
Description
Pascal Rapicault
While I agree this is a problem, I'm not sure this is the 'blocker'. If we are removing IUs and properly uninstalling them, then this is less of a concern. However, we are dropping IUs, but they not being unconfigured, and it's that combination that's killing us. The reason I bring this up, is because I don't know if we want to change the planner in an SR release. > While I agree this is a problem, I'm not sure this is the 'blocker'. If we are > removing IUs and properly uninstalling them, then this is less of a concern. > However, we are dropping IUs, but they not being unconfigured, and it's that > combination that's killing us. I don't the fix you are suggesting is correct. As discussed on the mailing list, I'm pretty sure that we could end up in situations where the bundles.info of shared install will not be a proper subset of the initial install and thus will break the user further down the road. > The reason I bring this up, is because I don't know if we want to change the planner in an SR release. We have changed this code many times before (including in point releases), and the number of dedicated tests we have in the area make me confident that we can fix this. We need to fix the problem where it is. (In reply to comment #2) > I don't the fix you are suggesting is correct. As discussed on the mailing > list, I'm pretty sure that we could end up in situations where the bundles.info > of shared install will not be a proper subset of the initial install and thus > will break the user further down the road. > This should be protected because we lock all the IUs in the shared profile. The reason that we are being bit right now is because the slf4j bundles are not in the profile -- our bundles.info file and p2 profile are out of sync. But I agree we should fix this at the root, I just want to make sure we understand all the options before we make the fix. If we're comfortable with changing the resolution code, then that's fine by me too. Created attachment 177183 [details]
fix for the epp problem
Here is a patch that fixes the whole EPP problem.
The problem lied in the optimization function.
Each installed packaged should be given a penalty, to make sure that the minimum number of packages are installed.
Because we prefer most recent packages (or installed ones) to older packages, we give an increased penalty to older packages. We have also a specific penalty for installed packages, to make sure that already installed packages are kept whenever possible.
In the specific case for which there was only one version of an IU, no penalty was given (e.g. one version of slf4j.jcp), so a solution with that package installed was optimal for SAT4J.
That patch makes sure that a minimum penalty is given to the IU when it appears in only one version (There is no need to consider here if the package is installed or not).
That behavior is around since the beginning of p2, but it was not a bug before when changed the behavior of the slicer.
Indeed, an element that appeared in the slicer in one version only had to be installed, thus there was no uncertainty on his state.
With the introduction of non greediness in the encoding, we broke that property, that makes the previous behavior buggy.
The fix is simple so can be integrated in SR1 without problem.
In my workspace, I met a bug in SAT4J when running the test EPPPackageInstallStability. I am not sure however that I was running the exact version of SAT4J that shipped with 3.6.
That bug was corrected in HEAD last month on SAT4J side. If needed, I can prepare either a new release of SAT4J, or a patched version of the version that ship with 3.6 with the fix for that bug.
Created attachment 177186 [details]
version of SAT4J core shipping with Eclipse with backported patch
Here is a new version of SAT4J core with only the fix for that bug.
Created attachment 177187 [details]
same version of SAT4J pb, updated metadata
No changes were needed here. A new bundle is necessary because we require a strict version of the core bundle.
After doing additional tests, I confirm that the proposed fix exposes indeed a bug in SAT4J. That was also confirmed by Pascal. That bug showed up last month and was fixed in HEAD. I simply backported the fix. http://websvn.ow2.org/diff.php?repname=sat4j&path=/maven/trunk/org.sat4j.core/src/main/java/org/sat4j/minisat/core/Solver.java&rev=754 I attached two new bundles for SAT4J. The changes in SAT4J are those lines in the core bundle (nothing in the pb one). Created attachment 177188 [details]
New fix, to avoid changing sat4j jars
Here is a new patch that prevents the bug present in SAT4J to show up (we mimic in that case the previous behavior).
Basically, the idea is to have an empty optimization function when the only available package is the request (so called meta-iu).
I have released in 3.6.1 the last patch Daniel attached. Fix released in HEAD and in 3.6.x Though for HEAD I have opened a new bug where the code is cleaned up a bit. There was a problem with tagging HEAD so this fix won't appear in integration builds until the first build after 3.7 M2. *** Bug 325666 has been marked as a duplicate of this bug. *** |