Community
Participate
Working Groups
I20080930-0921 1. Help > Software Update 2. Press "Revert Configuration..." Observe: The "Revert Software Configuration" dialog opens and select the first "Previous Configuration". At the same time an error dialog opens with the following details: The configuration snapshot is no longer valid. Cannot complete the install because some dependencies are not satisfiable Unsatisfied dependency: [SDKProfile 0.0.0.1222853206880] requiredCapability: org.eclipse.equinox.p2.iu/toolinggtk.linux.x86org.eclipse.core.runtime/[3.4.100.v20080714,3.4.100.v20080714] Unsatisfied dependency: [org.eclipse.sdk.ide 3.5.0.I20080923-0800] requiredCapability: org.eclipse.equinox.p2.iu/toolinggtk.linux.x86org.eclipse.core.runtime/[3.4.100.v20080714,3.4.100.v20080714] Unsatisfied dependency: [org.eclipse.sdk.ide 3.5.0.I20080923-0800] requiredCapability: org.eclipse.equinox.p2.iu/toolinggtk.linux.x86org.eclipse.core.runtime/[3.4.100.v20080714,3.4.100.v20080714]
Moving to correct bucket
This is the current expected behavior if you no longer have access to the old metadata. e.g. is the p2 metadata for I20080923-0800 still accessible from one of your metadata repos?
Sorry as a user I have no notion of p2 metadata. I just know about update sites. So yes my update sites are still there when I press the Manage Sites button. I have no idea if they still contain the metadata that you need. If they don't, I don't think failing like is the right way to tell the user that the configuration cannot be reverted.
I don't think there is much to be done here when the repository is missing, though I thought we were getting the metadata for previous configurations straight from the profile registry and never consulted the external repos. Anyway, we definitely need to provide a better error message.
see also bug #252376
(In reply to comment #4) > I don't think there is much to be done here when the repository is missing, > though I thought we were getting the metadata for previous configurations > straight from the profile registry and never consulted the external repos. > Anyway, we definitely need to provide a better error message. > We've gotten lots of user surprise over the fact that the network is contacted during a revert. So if it's possible to get everything from the profile registry, that would be great (as well as address all the UI freezes that are happening when a repo has to get loaded/reloaded during this workflow).
(In reply to comment #6) > We've gotten lots of user surprise over the fact that the network is contacted > during a revert. So if it's possible to get everything from the profile > registry, that would be great (as well as address all the UI freezes that are > happening when a repo has to get loaded/reloaded during this workflow). Agreed. Probably a good time to bite the bullet. Experiencing this first-hand while testing revert today.
I tentatively marked M5, but it may be something we can differ to M6 depending on what else needs to happen
*** Bug 252376 has been marked as a duplicate of this bug. ***
Keeping data in the profile registry can prevent most (all?) of these confusing errors. At any rate, in the cases where the revert cannot be completed, let's make sure the error messages in exceptions thrown by FormerState make sense to an end user, or else a status code is used so that the UI can detect it and make a prettier error.
I'm going to mark fixed as we've made this error handling redundant by using the profile registries history. Now that we can guarantee that we always will have the necessary IUs I think we re-enter the regular UI Install work flow. The error handling done in the old revert UI should not be used since we always can show what IUs/ properties where in a previous profile sanpshot. If there are problems in the engine reverting they will handled in the same way we handle any other install problems. For the eclipse team who are moving from I-build to I-build the most common problem that will be encountered is the lack of availability of the old artifacts however this particular problem will be less prevalent when dealing only with "release" artifacts.
