Description Christophe Elek 2003-02-18 07:36:12 EST

Christophe,

I was testing the problem you mentioned yesterday further. This is the scenario
to get it:

Install Root 1.0.0
Install efix e334
Install XYZBogus 1.0.1
Resulting configuration has XYZ 1.0.0.e334 orphaned and with a warning status.
Interestingly enough, reconciler copes with this state better - we have no warnings.

Since e334 is designed to patch Root 1.0.0, it stays enabled. However, it
includes a version of XYZ Feature (1.0.0.e334) that is included by XYZBogus as
well. So in reality, e334 should have been a XYZBogus patch. When we install
XYZBogus 1.0.1, it brings in the new version of XYZ (1.0.1), and we have a problem.

Ideally, the result should be that XYZ 1.0.0.e334 is disabled and that e334
resolves to XYZ 1.0.1 using best match. Indeed, this is how reconciler sees
things. I think our problem comes from the fact that when XYZBogus 1.0.1 is
installed, XYZBogus 1.0.0 is disabled, but XYZFeature 1.0.0.e334 cannot be
disabled because it is still referenced by the efix e334.

I checked the code and I can see why this is happening - recursive
'IConfiguredSite.unconfigure' is validating parent when in children. I don't
know how to fix this, but I know that somehow we should be able to tell it that
it can disable XYZ 1.0.0.e334 because a better one is available.

Maybe we should modify validateNoConfiguredParents() to be more flexible and
works like follows:

If a child feature is to be unconfigured and it has other parents:

If a parent includes this child with 'perfect' match, we should work as today
If a parent includes this child with a best match (equivalent, compatible etc.)
see if newer features that satisfy match are enabled. If so, ignore this parent
i.e. act as though it does not exist.

Essentially, rule '2' would handle the case where we are too rigid in checking
for multiple parents where the second parent factored in child upgrades already
(because it is using a non-perfect match on the 'includes' element).

This is the method that would need to be changed:

	private boolean validateNoConfiguredParents(IFeature feature) throws
CoreException {
		if (feature == null) {
			UpdateManagerPlugin.warn("ConfigurationPolicy: validate Feature is null");
			return true;
		}

		IFeatureReference[] parents = UpdateManagerUtils.getParentFeatures(feature, 
		                     getConfiguredFeatures(), false);
		return (parents.length == 0);
	}

Since 'UpdateManagerUtils.getParentFeatures' is used elsewhere, I suggest
writing a new method that does exactly what we need in this context to contain
risk. You can make a copy of 'getParentFeatures' and start changing it to return
only 'perfect' parents. Parents that have better children that are within their
'match' limit should not be returned. Better yet, don't even return parent array
- name the method as follows:

UpdateManagerUtils.hasPerfectParents(IFeature childFeature, IFeatureReference []
configuredFeatures);

The call would look like:

	private boolean validateNoConfiguredParents(IFeature feature) throws
CoreException {
		if (feature == null) {
			UpdateManagerPlugin.warn("ConfigurationPolicy: validate Feature is null");
			return true;
		}

		return UpdateManagerUtils.hasPerfectParents(feature, getConfiguredFeatures());
	}