Community
Participate
Working Groups
While investigating what is going wrong in shared installs, I came across the following issue that is probably the root cause of the problem for shared installs. The resolution is not stable when being re-run. To be more precise, when I try to install an IU in the context of some repositories, then cause a re-resolution of the resulting profile, IUs are being dropped. Even though this looks not important, because internally p2 re-resolves the current profile to generate the attachment of IUs, this ends up being a key issue. To show the problem, I have released a test case called EPPPackageInstallStability in the 3.6 branch. At this point I have not found a way to solve this problem.
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. ***
