Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #270195 +++ 3.5 M6 Martin had a case where a bundle from dropins remained installed into the profile even after being deleted from disk. This resulted in a broken installation. I think the case is: 1) Install bundle a version 1.0 via dropins 2) Install bundle b requiring 'a' [1.0,2.0) via normal install 3) Shutdown, replace a 1.0 in dropins with a 2.0 (actually changed value of .link file to point to newer version) 4) Restart. 'a' 1.0 is still in the profile (presumably because it's required by bundle 'b', however it no longer exists on disk)
In bug 270195 we discussed a couple of approaches to fix this problem but they need more investigation. I opened this bug to track the progress and we will use bug 270195 to track the release of the #move issues as discussed in part one of bug 290195 comment 17. Initial code will be released (and disabled) as part of the fix for bug 270195. Marking as 3.6.1 target so we don't lose track of it. Copying John's comments from b 270195 c 30: However I'm worried about part 2), in particular marking strict roots as optional. I see that this will handle the case where the strict root requires something that has been deleted, but I'm worried it will cause strict roots to be uninstalled in other scenarios. From my point of view, uninstalling a strict root should *never* happen unless it is completely impossible for it to remain installed (like its dependencies have been deleted. For example imagine a case like this: A is installed strict, depends on C [1.0,1.1) B is installed optional, depends on C [2.0,3.0) B, c 1.0 and c 2.0 are in dropins. Normally, the planner will pick (A, C 1.0). However if A is marked optional, it might instead pick (B, C 2.0) since that solution is equally valid. Now we have uninstalled a strict root in order to satisfy an optional root. This is one example, but I'm worried there might be other side-effects like this from marking strict roots as optional here.
From bug 270195 comment #43: Let me state here my original use case (which might be a helpful test case for this once it's done): 1.) Download eclipse-SDK-3.6Mx.zip 2.) Add *.link file pointing to emf-2.5 extension location 3.) In the UI, install something that depends on EMF, e.g. GMF or TM-discovery 4.) Replace the *.link file by a new one pointing to emf-2.6 ext.loc. Since I expect the EMF "update" to be fully compatible, I expect the whole environment to come up properly again. I'd never expect anything that I installed from the UI to be removed. In the worst case (that I really broke some dependency, which I personally am pretty sure I never did since the "update" should be compatible) I would expect my UI-installed extension to be flagged with an error marker, such that I can "repair" my install by reverting to emf-2.5. I think my original use case as per comment 0 was not using EMF but the CDT, and a DSDP-TM addon that depends on the CDT. We have since migrated that addon into the CDT, so the original case isn't easily reproducable any more. But I am very sure that I didn't break any version range (as John indicates in comment 0 points 2) and 3) with the [1.0,2.0) version range). Hope that helps!
Slipping target milestone due to outstanding issues but consider for 3.6.1+.
Move all 3.8 bugs to Juno.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
