Bug 313795

Comment 1 DJ Houghton 2010-05-20 15:08:34 EDT

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.

Comment 2 DJ Houghton 2010-05-21 09:30:45 EDT

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!

Comment 3 DJ Houghton 2010-08-18 14:07:13 EDT

Slipping target milestone due to outstanding issues but consider for 3.6.1+.

Comment 4 Thomas Watson 2011-06-08 11:30:56 EDT

Move all 3.8 bugs to Juno.

Comment 5 Eclipse Genie 2019-06-29 02:08:55 EDT

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.