applying a feature patch when its name has changed #1288
Replies: 4 comments 6 replies
-
|
It sounds like you are trying to install this when the installation still has the old name. Is that the case?
|
Beta Was this translation helpful? Give feedback.
-
|
@merks - thanks. yes, I am trying to install this patch (with new name, I understand the installer cannot figure out the parent feature for which this is a patch, but this is where we are! any workaround is appreciated! |
Beta Was this translation helpful? Give feedback.
-
|
I’m more confused though because this is a bundle not a feature so I have no mental model for what exactly you are doing. |
Beta Was this translation helpful? Give feedback.
-
|
oops! apologies for confusing you. a feature that consumed |
Beta Was this translation helpful? Give feedback.
-
|
Are you sure the error is related to the bouncycastle thing at all? Note the we’ve generally been removing includes of 3rd party plugins. |
Beta Was this translation helpful? Give feedback.
-
|
yes, I guess this dependency is removed from master, (may be this: eclipse-equinox/p2@f885ca8) but we do have it still in 4.23 maintenance. I could remove from there too, but unsure about any implications! also would like to know the recommended method of patching in such scenarios (in cases where we really need those). thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Main implication is that maybe both bundles will be installed, but feature patches are somehow "special" ... |
Beta Was this translation helpful? Give feedback.
-
|
Yes, if you don't specify it in a feature, nothing is likely to update the bundle itself. Moreover nothing is likely to remove the older named bundle and replace it with the newer named bundle. But I still don't understand why a feature patch should not allow an additional bundle to be added or some bundle to be removed from the feature itself. You might even need a negative requirements via p2.inf to remove the older named versions from the installation. It's definitely a trick problem! |
Beta Was this translation helpful? Give feedback.
-
|
Something that might work is to use p2.inf to specify an IU with the old name, but a newer version, specify that in the feature patch, and synthesize that IU to require the newly named IU so that the update would be happy to see the old thing being updated and that update would also force the new thing to be installed: |
Beta Was this translation helpful? Give feedback.
-
|
Every Iu has an Update ID so one might be able to make it even updatable, but in the end why bother at all? P2 will simply fetch the new one if it is required, the worst that can happen is that the old lingers around but no one is using that... While with enforce it to uninstall, it might lead to the patch being not installable at all because someone else in the system still need it... |
Beta Was this translation helpful? Give feedback.
-
I have a feature of which the name has changed in a later version. I created a feature patch with the new name, but the p2 installer is refusing to install the patch, as it doesn't know the parent feature on which to install this. any ideas?
this is the error I get:
Equinox P2 CORE Feature Patch (bugzillas 128,247)” is not applicable to the current configuration and will not be installed.thanks in advance!
Beta Was this translation helpful? Give feedback.
All reactions