[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[p2-dev] Update, shared installs, and EPP Package
- From: Pascal Rapicault <pascal@xxxxxxxxxxxx>
- Date: Wed, 1 Sep 2010 12:28:58 -0400
- Delivered-to: email@example.com
The issue in the shared install revealed a problem in the p2 resolver, and it got fixed in 3.6.1.
Still, a problem exists with the update path. Indeed, users of most EPP packages who will try to update from SR0 to SR1 will end up with a configuration that will be invalid (remember that 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 (remember this is now the default case for Windows 7), the initial issue of shared install will appear like it has not been fixed for them.
So what do we do:
There are two possibilities:
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
At this point I recommend that we go with #2 because even though the changes are code related those bundles will most likely be harmless and it offers to best happy path for most users.
What do you think?