Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] [epp-dev] EPP packages and shared install

Hi Markus,

The addition of this bundle is something each package maintainer should do on their side or just on EPP feature?

On Sun, Sep 5, 2010 at 08:14, Markus Knauer <mknauer@xxxxxxxxxxxxxxxxx> wrote:
I read the discussion on the p2 mailing list on Friday. For me (and hopefully for most other people) is the first proposed solution not a solution that I would like to explain to any users. It would look like an upgrade from Galileo to Helios is possible, whereas a simple update from one Helios release to a Helios service release is not possible.

My favourite would be the second solution. I think the additional bundle that is necessary to satisfy all dependencies is an acceptable change and we could add this dependency in the common EPP feature that is included in all EPP packages.

What are the opinions of other package maintainers?

And would it be possible that the p2 team helps testing the new SR1 packages including update scenarios from the Helios release to the service release?

Thanks and regards,
Markus



On 4 September 2010 21:16, Pascal Rapicault <pascal@xxxxxxxxxxxx> wrote:
Action requested for SR1.

What is the problem?
People running EPP Packages in shared installed mode [1] can not install plugins through any mean (cmd line, standard p2, connector UI, or Eclipse Market Place). To be precise, the installation will appear to have have succeeded but because of inconsistencies in config files, the plugins will not be picked up. The underlying problem in p2 has been fixed in SR1. 
Unfortunately there is still a problematic situation: users of most EPP packages who will try to update from SR0 to SR1 will end up with a configuration that will be invalid (we are running the 3.6.0 code to actually do the update). The resulting installation may look successful but if they ever use it in shared install mode the initial issue will appear like if it has not been addressed.

What are the solutions?
1) Prevent the SR1 packages to be seen as an update of the SR0s. This can be done by tweaking the metadata in the top level IU of each package to exclude SR0 from the list.
Pros: Simple metadata change
Cons: No update possible from SR0

2) Add the SLF4J JCL bundle to each EPP Package in SR1. Though this may appear to be a weird fix, this will result in a consistent installation. The background here is the SLF4J bundles were being brought in the epp packages because of the p2 bug and again because of the bug their uninstallation was leaving the system in an inconsistent state. The idea of having those bundles be part of the SR1 packages is that when the update occurs the uninstallation of these bundles will not occur thus leaving the installation in a consistent state.
Pros: Everybody can update 
Cons: "Code change" in that we ship a new bundles


PaScaL

[1] - Shared install mode describes a situation where the eclipse installation is read only for the user, for example installed by a super user on linux, and run by a user with less privs. It use to be a very rare mode of operation for Eclipse, however this situation has changed with Windows 7 (and Vista) where as soon as Eclipse is installed in "Program Files", eclipse ends up running in this mode.



_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epp-dev




--
Thanks,

Daniel Pastore
Sequoyah Team


Back to the top