Bugzilla – Full Text Bug Listing
| Summary: | Product IU in Kepler packages should have new property | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Technology] EPP | Reporter: | Pascal Rapicault <pascal> | ||||||
| Component: | Packager | Assignee: | Project Inbox <epp.packager-inbox> | ||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | david_williams, ian.skerrett, irbull, mknauer, mober.at+eclipse, pascal.rapicault, reckord, stryker, t-oberlies | ||||||
| Version: | 2.0.0 | ||||||||
| Target Milestone: | 2.0.0 RC1 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Pascal Rapicault
So to make sure that ppl don't run into weird situations, it would be great if this property could be added to the products. For this there is currently two ways to do it: - add the property in the p2.inf - build with the most recent version of p2 publisher For an example of what we did for the platform, see bug 406947. Once we verify that this works, we can do something similar for EPP. (In reply to comment #1) > - build with the most recent version of p2 publisher Using Buckminster headless-4.3 for metadata / branding plugin creation; and Eclipse SDK build S-4.3M7-201305020800 for assembling the packages with the director. (In reply to comment #1) > - add the property in the p2.inf Here it's not really clear to me if we have to do anything at all in EPP? And *if* we need to, what and where? The reason is that EPP is sitting on top of the platform and doesn't define (yet) a standalone 'product'; see config.ini: eclipse.product=org.eclipse.platform.ide Looking into the content.jar that is currently available in /releases/staging:
<unit id='org.eclipse.platform.ide' version='4.3.0.I20130502-0800'>
...
<properties size='4'>
<property name='org.eclipse.equinox.p2.name' value='Eclipse Platform'/>
<property name='lineUp' value='true'/>
<property name='org.eclipse.equinox.p2.type.group' value='true'/>
<property name='org.eclipse.equinox.p2.type.product' value='true'/>
</properties>
Since we (EPP) kind of 'inherit' this product IU, I would say we are safe.
Pascal, could you confirm this... other opinions or anything else we should check?
[{(I'd download a recent package build and test this one but with the current network situation this takes ages...)}]
Nope, that didn't work so far. I am still able to destroy my Eclipse RCP/RAP package by installing RT Components (not meant for the IDE!) from the Kepler repository into my IDE by ignoring many warnings in the p2 install wizard. *** Bug 408554 has been marked as a duplicate of this bug. *** The question from comment 4 isn't solved yet and I haven't found the time to look into this. Anyone any suggestions? (In reply to comment #7) > The question from comment 4 isn't solved yet and I haven't found the time to > look into this. Anyone any suggestions? What is the worst thing that could happen if we simply adjust the p2.inf of the epp common feature (or the various package features or product bundles? I don't know) to include the property that Pascal wants ? Might be worth a try since I can't quite see what we could possibly break. Or, perhaps as per comment #1, simply build with the most recent version of p2 publisher ? Then the "*.product" file of all epp packages should result in the respective property being added to the product IU, no ? > - build with the most recent version of p2 publisher (In reply to comment #8) > What is the worst thing that could happen if we simply adjust the p2.inf of > the epp common feature (or the various package features or product bundles? > I don't know) to include the property that Pascal wants ? It needs to be in all features (I guess)... I tried to update Buckminster to the latest version and the p2 director (see comment 3) but that didn't help. > Here it's not really clear to me if we have to do anything at all in EPP? > And *if* we need to, what and where? The reason is that EPP is sitting on > top of the platform and doesn't define (yet) a standalone 'product'; see > config.ini: > > eclipse.product=org.eclipse.platform.ide I had not noticed that the package included the eclipse product. So you are right you should not have anything to do. Now based on this observation I checked the p2 code that verify if there is a product already installed and I noticed that it only checks for the product markup on the root IUs. This means that even though the epp packages include a product p2 will not detect them as such. I think this should be fixed in p2. I've opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=408996 Great, Pascal. Your help is very welcome! (I didn't find the time to dig into this yet... pretty busy weeks) *** Bug 409019 has been marked as a duplicate of this bug. *** Markus, Pascal, do you have a timeframe when this will be fixed? Will a fix make it into RC2? We are thinking of switching remediation off by default for MPC in RC2 if it doesn't, so users don't accidentally kill their installation. (In reply to comment #14) > Markus, Pascal, do you have a timeframe when this will be fixed? Will a fix > make it into RC2? We are thinking of switching remediation off by default > for MPC in RC2 if it doesn't, so users don't accidentally kill their > installation. When looking at the EPP packages, I realized that they did not follow the typical structure of "products" (my expectation was that the product IU was always installed as a root). The problem with this is that it does not match the assumption under which the p2 code works and therefore causes the problem we've seen. Given that this is a case that I (nor Ian B.) did not think could happen, but now happens, I believe that the right fix is to change p2 to handle the situation (https://bugs.eclipse.org/bugs/show_bug.cgi?id=408996) but this is only going to happen in RC3, and this is why we decided to do nothing in the EPP packages themselves. Now if you think we need something before RC3, then I think that we should change the EPP packages to include the necessary property and not wait for the RC3 code change rather than disabling the remediation in MPC. Also you need to know that MPC is not the only impacted and the same problem would occur with normal p2 for which the remediation can not be disabled. (In reply to comment #15) > Now if you think we need something before RC3, then I think that we should > change the EPP packages to include the necessary property and not wait for > the RC3 code change rather than disabling the remediation in MPC. > Also you need to know that MPC is not the only impacted and the same problem > would occur with normal p2 for which the remediation can not be disabled. RC3 is very late in the release cycle for a bug this critical. What do we do if it is not fixed in RC3? Will this bug also impact any of the solutions that are listed on MPC? For instance, if a product is not setup accordingly to the assumptions of the p2 remediation, will this result in the product being uninstalled? I am certain that there will be a number of product listing on Marketplace that aren't setup correctly. We can't assume that people will correct their p2 update site just because MPC now has the p2 remediation. (In reply to comment #16) > (In reply to comment #15) > > Now if you think we need something before RC3, then I think that we should > > change the EPP packages to include the necessary property and not wait for > > the RC3 code change rather than disabling the remediation in MPC. > > Also you need to know that MPC is not the only impacted and the same problem > > would occur with normal p2 for which the remediation can not be disabled. > > RC3 is very late in the release cycle for a bug this critical. What do we do > if it is not fixed in RC3? This patch is going to go in. It is ready to go. I'm just waiting on the appropriate approval before committing it. > Will this bug also impact any of the solutions that are listed on MPC? For > instance, if a product is not setup accordingly to the assumptions of the p2 > remediation, will this result in the product being uninstalled? I am > certain that there will be a number of product listing on Marketplace that > aren't setup correctly. We can't assume that people will correct their p2 > update site just because MPC now has the p2 remediation. Does MPC allow to install complete applications and by this I mean that it delivers an executable, splash screen, etc (think of it like RCP app)? (In reply to comment #17) > (In reply to comment #16) > > (In reply to comment #15) > > > Now if you think we need something before RC3, then I think that we should > > > change the EPP packages to include the necessary property and not wait for > > > the RC3 code change rather than disabling the remediation in MPC. > > > Also you need to know that MPC is not the only impacted and the same problem > > > would occur with normal p2 for which the remediation can not be disabled. > > > > RC3 is very late in the release cycle for a bug this critical. What do we do > > if it is not fixed in RC3? > This patch is going to go in. It is ready to go. I'm just waiting on the > appropriate approval before committing it. OK but this gives us very little time to actually test it in MPC and if we find a problem we are basically left with a delay to the release train. > > > Will this bug also impact any of the solutions that are listed on MPC? For > > instance, if a product is not setup accordingly to the assumptions of the p2 > > remediation, will this result in the product being uninstalled? I am > > certain that there will be a number of product listing on Marketplace that > > aren't setup correctly. We can't assume that people will correct their p2 > > update site just because MPC now has the p2 remediation. > Does MPC allow to install complete applications and by this I mean that > it delivers an executable, splash screen, etc (think of it like RCP app)? Sure, why not? (In reply to comment #18) > (In reply to comment #17) > > (In reply to comment #16) > > > (In reply to comment #15) > > > > Now if you think we need something before RC3, then I think that we should > > > > change the EPP packages to include the necessary property and not wait for > > > > the RC3 code change rather than disabling the remediation in MPC. > > > > Also you need to know that MPC is not the only impacted and the same problem > > > > would occur with normal p2 for which the remediation can not be disabled. > > > > > > RC3 is very late in the release cycle for a bug this critical. What do we do > > > if it is not fixed in RC3? > > This patch is going to go in. It is ready to go. I'm just waiting on the > > appropriate approval before committing it. > > > OK but this gives us very little time to actually test it in MPC and if we > find a problem we are basically left with a delay to the release train. We have very little time I agree, unfortunately the RC2 build of the platform has already shipped (http://download.eclipse.org/eclipse/downloads/), which is why I was suggesting to fix the EPP packages which could give us something to use in RC2 testing of the EPP package. As for delaying the release train I think you are bit too worried as the release of RC3 is due in two days (May 29th http://www.eclipse.org/eclipse/development/plans/freeze_plan_4_3.php) which give us another 3 weeks to fix any issue. > > > Will this bug also impact any of the solutions that are listed on MPC? For > > > instance, if a product is not setup accordingly to the assumptions of the p2 > > > remediation, will this result in the product being uninstalled? I am > > > certain that there will be a number of product listing on Marketplace that > > > aren't setup correctly. We can't assume that people will correct their p2 > > > update site just because MPC now has the p2 remediation. > > Does MPC allow to install complete applications and by this I mean that > > it delivers an executable, splash screen, etc (think of it like RCP app)? > > Sure, why not? This was not a rhetorical question :) I was trying to understand the exact scenario you were worried. For example if MPC allows complete products to be installed, then this should not be a problem because then the product will not ship with a new version of p2 that includes remediation. (In reply to comment #19) > (In reply to comment #18) > > (In reply to comment #17) > > > (In reply to comment #16) > > > > (In reply to comment #15) > > > > > Now if you think we need something before RC3, then I think that we should > > > > > change the EPP packages to include the necessary property and not wait for > > > > > the RC3 code change rather than disabling the remediation in MPC. > > > > > Also you need to know that MPC is not the only impacted and the same problem > > > > > would occur with normal p2 for which the remediation can not be disabled. > > > > > > > > RC3 is very late in the release cycle for a bug this critical. What do we do > > > > if it is not fixed in RC3? > > > This patch is going to go in. It is ready to go. I'm just waiting on the > > > appropriate approval before committing it. > > > > > > OK but this gives us very little time to actually test it in MPC and if we > > find a problem we are basically left with a delay to the release train. > We have very little time I agree, unfortunately the RC2 build of the > platform has already shipped > (http://download.eclipse.org/eclipse/downloads/), > which is why I was suggesting to fix the EPP packages which could give us > something to use in RC2 testing of the EPP package. > As for delaying the release train I think you are bit too worried as the > release of RC3 is due in two days (May 29th > http://www.eclipse.org/eclipse/development/plans/freeze_plan_4_3.php) which > give us another 3 weeks to fix any issue. > > The EPP packages, which include MPC, are not available until June 7 and RC4 is the final. I am interested in testing the packages and MPC. Created attachment 231599 [details]
Patch adding the metadata
Here is a recap of the situation. The p2 fix I mentioned in comment #11 (which is from an engineering pov the proper way of handling this issue) has been committed and will be available in RC3. However in order to help with the testing of the remediation support in the context of MPC (bug #409019) in the RC2 time frame, I'm asking someone from the EPP project to release this patch. As described in the original comment the patch consists in adding to all product IUs a property called 'org.eclipse.equinox.p2.type.product' and set it to 'true'. With a locally produced build, I have tested the original scenario that Ian S ran into in the context of #409019, and as expected the remediation does not find any solution and thus does uninstall the executable. In short all is good :) That said, as I mention early, this is not this is not an ideal fix and I think that once EPP packs are built with RC3 then we should revert this patch. (In reply to comment #22) > > With a locally produced build, I have tested the original scenario that Ian > S ran into in the context of #409019, and as expected the remediation does > not find any solution and thus does uninstall the executable. In short all > is good :) To be clear, I think you meant 'and thus does *not* uninstall the executable. No? I am hoping remediation should never uninstall my Eclipse installation. (In reply to comment #23) > (In reply to comment #22) > > > > With a locally produced build, I have tested the original scenario that Ian > > S ran into in the context of #409019, and as expected the remediation does > > not find any solution and thus does uninstall the executable. In short all > > is good :) > > To be clear, I think you meant 'and thus does *not* uninstall the > executable. No? I am hoping remediation should never uninstall my Eclipse > installation. Aouch :) yes. this is what I meant :) Patch from comment 21 applied to master with commit 037bf47a74bad1f0199030a3400a32b0e88f39a9 Created attachment 231662 [details]
Screen shot of MPC error
I pulled down the RC2 nightly Standard package. I tried to install JBoss Developer Studio (Juno) and I seem to get the error message that I thought remediation was suppose to catch. The error is 'Cannot complete the install because of conflicting dependency. Screen shot is attached. (In reply to comment #27) > I pulled down the RC2 nightly Standard package. I tried to install JBoss > Developer Studio (Juno) and I seem to get the error message that I thought > remediation was suppose to catch. The error is 'Cannot complete the install > because of conflicting dependency. Screen shot is attached. Sorry I put this on the wrong bug. This bug still appears "NEW" for me, isn't this fixed by now in Kepler ? Closing. Yes, that was fixed in Kepler. |