Begin forwarded message: Date: September 6, 2010 8:19:53 PM EDT
Subject: Re: [epp-dev] [cross-project-issues-dev] EPP packages and shared install
Sounds like adding the bundle to epp
feature is best solution. But just to be explicit, here's a few more questions
...
Are you sure (I'd assume so) that it
_has_ to be added to _each_ EPP package? For example, JEE EPP has org.apache.commons.logging
in it already, and I seem to recall something about "one logger"
had to be present? (But I've only skimmed the technical discussions ...
and not sure exactly what bugs/issues are involved).
Despite the presence of the commons.logging in the packages, it should still be added. The bug has nothing to do with the loggers themselves but with the unexpected presence of those slf4j bundles that were being brought in by the resolver. What's effect/plan for SR2? I guess
we'd just leave it there in feature for simplicity (to cover all cases,
such as someone updating directly from initial release to SR2) but just
thought I'd ask. Are we stuck with it forever?
For SR2, the easiest would be to keep those bundles. Other solutions would be disable the ability to update from SR0 to SR2 directly and instead force a staged update through SR1 (since SR1 will contain the resolver fix. And remember when we update to SR1, SR0 is still being run.). What's effect/plan for Indigo? I'd assume
no longer included in package feature, but would update from Helios initial
release to Indigo initial release work ok? Or still end up with invalid
install, unless this extra bundle provided? (I'm not sure we need to "support"
this case, exactly (we could assume EPP users had service applied), but
should at least be documented).
The problem being in the initial state (Helios SR0), for Indigo we can either keep the workaround being introduced (which I would not like), or disable update from Helios SR0 to Indigo. Other paths from Helios SR0 to Indigo should still be supported. To me, this question raises the more general issue of whether or not we want to upgrade between trains? As this been discussed at the planning council?
Thanks for working through this "deep"
problem.
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
_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epp-dev
|
