Community
Participate
Working Groups
Use latest nightly build + update core and update ui Install Root 1.0.0 Install efix 334 update to root 1.0.1 efix 334 is not disabled
tried again, cannot reproduce
reproduced with 334 only
reproduced in M3. regression.
Testing with 20030115, e334 is correctly disabled when Root 1.0.1 is installed, but XYZ 1.0.0.e334 stays around. This is a must-fix for the release.
Christophe, the bug is in ConfiguredSite.java, line 398 (verify no enable parent). When XYZ 1.0.0 is unconfigured, we search if it has patches that reference it to unconfigure them as well. We find e334 and unconfigure it, then proceed to unconfigure its children. When we try to unconfigure XYZ 1.0.0.e334, it fails the check at the mentioned line and returns. We used to have this fixed by carefully lining up the order of features to unconfigure, so we must have broken it since. Please check the original code (2.0.2) to see what is different.
Not a regression, we had the bug in 2.0.2 Need to be fixed.
Action Taken: There is a method in UpdateManagerUtils that returns the list of 'parents' of a feature. This list is used to make sure we do not 'disable' a feature that is a children of another enable feature. The code we have was comparing all the 'best match' children with the feature to disable. It should only compare the 'real' children. In our case we were attempting to disable the EFIX feature. We then attempted to disable its children: the e344 efix. Root 1.0 and its children were not yet disable. So XYZ_BOGUS Feature 1.0.0 was considered an enable parent of Feature e334 because its included best match was efix334. We ought to realize that efix334 was only a best match. The solution is to calculate the 'real' parents of a feature instead of the 'best match' parent. Fixed UpdateManagerUtils.getParentFeatures(). It fixes this specific problem. Action Plan: test the whole optional scenario
Fixed, test in M5
