Bugzilla – Full Text Bug Listing
| Summary: | EPP configuration problem prevents shared installs from working | ||
|---|---|---|---|
| Product: | [Technology] EPP | Reporter: | Ian Bull <irbull> |
| Component: | Packager | Assignee: | Project Inbox <epp.packager-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | aniefer, aromero, blueser, bzt, david_williams, francisu, jacek.pospychala, jules, krzysztof.daniel, leden.os, loskutov, lpurvis, m.winter, maciej.oledzki, mknauer, mober.at+eclipse, niels, pascal, pwebster, remy.suen, richjddavis, spektom, steffen.pingel, trondvalen, zvikico |
| Version: | unspecified | ||
| Target Milestone: | 1.3.0 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | 323322 | ||
| Bug Blocks: | |||
|
Description
Ian Bull
I've also brought this up on the p2-dev list [1] and the epp-dev list [2]. [1] http://dev.eclipse.org/mhonarc/lists/p2-dev/msg03316.html [2] http://dev.eclipse.org/mhonarc/lists/epp-dev/msg01135.html I should also say that I think this is a relatively important problem since users cannot use the MPC on some of our more popular operating systems (Windows 7 / Vista), and that was supposed to be a pretty big feature from Helios. We have also had at least 8 bugs reported since July on this issue, so it does appear to be affecting end users. I've talked to Markus and this is the director call that is used to create the EPP Packages:
${ECLIPSE} -nosplash -consoleLog -application org.eclipse.equinox.p2.director \
-m ${METADATAREPOSITORIES} -a ${ARTIFACTREPOSITORIES} \
-installIU ${PACKAGE} \
-destination ${PACKAGE_BUILD_DIR}/eclipse \
-profile ${PACKAGE} \
-flavor tooling \
-profileproperties org.eclipse.update.install.features=true \
-bundlepool ${PACKAGE_BUILD_DIR}/eclipse \
-purgeHistory \
-p2.os ${OSes[$index]} \
-p2.ws ${WSes[$index]} \
-p2.arch ${ARCHes[$index]} \
-roaming \
-vm ${JRE} \
-vmargs -Declipse.p2.mirrors=false -Declipse.p2.data.area=${PACKAGE_BUILD_DIR}/eclipse/p2 \
2>&1 >${DOWNLOAD_DIR}/${PACKAGE}_${EXTENSION}.log
After a lot of investigation, it appears that this problem is actually a problem with the p2 director. The p2 director is removing some bundles, but not actually unconfiguring them (removing them from the bundles.info file). To recap, this is a p2 problem, caused by an EPP configuration problem caused by a p2 bug. I have found two p2 director bugs, and it's the combination of these bugs that actually leading to this. See bug 322970 and 322971. Some combination of these bugs needs to be fixed for 3.6.1. (In reply to comment #3) > To recap, this is a p2 problem, caused by an EPP configuration problem caused > by a p2 bug. Now *I* am a bit confused by this chain of problems ;-) What's the p2 problem, what's the p2 bug, and most important from *my* point of view: What is the EPP configuration problem and what can do to help solve this problem? Is it connected to the way we use the bundlepool, purgeHistory, roaming, or the eclipse.p2.data.area? So the p2 problem is that shared installs don't work if we have an inconsistent bundles.info / p2 profile. This is not really a bug (garbage in / garbage out). The EPP configuration problem is the fact that EPP packages are shipping with inconsistent bundles.info / p2 profiles. The p2 bug is in the director, and it's causing EPP packages to be configured incorrectly. Confused yet ;). We can probably fix up the director command a bit. Pascal mentioned that we don't need the eclipse.p2.data.area anymore, but that's not causing this issue. btw, what version of Eclipse do you use to run the director from? Do you use the most recent build (i.e. did you use 3.6.0 to run the director to create the Helios packages). (In reply to comment #5) > btw, what version of Eclipse do you use to run the director from? Do you use > the most recent build (i.e. did you use 3.6.0 to run the director to create the > Helios packages). The packages of the Helios release in June have been created with the S-3.6RC4-201006031500 SDK build. *** Bug 320153 has been marked as a duplicate of this bug. *** *** Bug 317896 has been marked as a duplicate of this bug. *** *** Bug 321239 has been marked as a duplicate of this bug. *** *** Bug 320383 has been marked as a duplicate of this bug. *** *** Bug 317757 has been marked as a duplicate of this bug. *** Maybe someone can confirm that it is only the bundle "org.slf4j.api" that is missing. We are not talking about additional ones, right? The reason why I am asking is because some other bug reports (e.g. bug 317757) are mentioning additional bundles. *** Bug 324648 has been marked as a duplicate of this bug. *** I'm arriving in Germany today, so I can work directly with Markus to help get the final parts in place. 1. We need to make sure that EPP is using a 'new' (fixed) -- i.e. a 3.6.1 director application. 2. We need up update the EPP Paackage to include the needed bundles. (In reply to comment #14) > 1. We need to make sure that EPP is using a 'new' (fixed) -- i.e. a 3.6.1 > director application. I'm slightly confused at this point... since bug 322970 and bug 322971 which have been mentioned in comment 3 as being the root cause have not been fixed yet? Has a different solution been found for EPP to included the needed bundles, and what does it mean for consumers other than EPP that these bugs are not fixed? BTW, including the SLF4J jars in EPP packages, may have a side effect of increased logging in console window from Help Server. See bug 324922 and 316621. (Which would not be good). (In reply to comment #14) > 1. We need to make sure that EPP is using a 'new' (fixed) -- i.e. a 3.6.1 > director application. EPP builds since this Tuesday are using the p2 director from the Eclipse SDK build M20100902-1717. If there is a better one, please let me know and I will update it again. > 2. We need up update the EPP Paackage to include the needed bundles. I do have a dependency to the bundle "org.slf4j.api"; at the moment I am waiting for my download to finish to see whether this dependency is enough. On the other hand there are reports about side effects if the slf4j bundle is included in the packages. My hope was that we don't see any changes in the behaviour of the packages if we include this bundle in all packages, but now I become very suspicious if including it is a solution at all. I compared the EPP RCP/RAP package (linux, x86_64) in the Helios R version and in the last nightly build (http://build.eclipse.org/technology/epp/epp_build/36/download/20100910-0235/) The bundles.info file is the same in both cases (except the different versions of the bundles, of course). The list of plugins differs and if I didn't overlook any differences, the following bundles are new in the last nightly build: ch.qos.logback.classic_0.9.19.v20100519-1505.jar ch.qos.logback.core_0.9.19.v20100419-1216.jar ch.qos.logback.slf4j_0.9.19.v20100519-1910.jar javax.mail.glassfish_1.4.1.v201005082020.jar org.eclipse.net4j.jms.api_3.0.0.v20100614-1655 org.slf4j.api_1.5.11.v20100519-1910.jar That list seems to correspond to the list in bundles.info (old and new). The drawback is that there is a lot of noise in the log, especially from the Eclipse help system and I cannot say if there are any other effects that I haven't found or if other packages behave differently! (Apart from that there are many source bundles missing in the new build, such as org.apache.commons.codec.source, but that doesn't look critical to me and it is another issue.) I'll document my concern here, with automatically including all these loggers, for everyone, since doing so has side effects. Even if we could "get around" the known side effects, I'd be concerned that there could be additional side effects, such as interfering with someone else's logging solution, that we could not detect until too late and basically have no control over. This logging stuff is complicated. Would the following approach provide an alternative ... ? What if we had a "special feature", that included these loggers. Then, for people having problems, they could be directed to install that special feature (or, start fresh with SR1). So, no automatic fixes, but at least provides an "out" for those with issues, without as much risk to those having no issues at all. Then ... icing on the cake ... would uninstalling the special "loggingWorkaround" feature end up righting everything? (At least, assuming they had upgraded to 3.6.1, that is)? If this alternative approach would work, seems like it would also provide something of a practical alternative to other "products" that might have similar problems? But, I'm just guessing at alternative solutions. Mostly just wanted to go record about my concerns about including the loggers. Maybe I was naive and had the wrong expectations, but I expected no behavior changes by including the extra logger(s). Also, if we consider going to "plan b", I'm not sure we should "lock out" all updates to SR1, since this problem effects only some users on some platforms (right?). Granted, a very popular platform, but seems kind of heavy handed to say no one can. Can the "update lock out" solution be made platform specific? Thanks all ... I'm perfectly willing to go with the group's decision (or Markus's :) ... just thought I'd document my concerns. (In reply to comment #15) > (In reply to comment #14) > > > 1. We need to make sure that EPP is using a 'new' (fixed) -- i.e. a 3.6.1 > > director application. > > I'm slightly confused at this point... since bug 322970 and bug 322971 which > have been mentioned in comment 3 as being the root cause have not been fixed > yet? Sorry Martin, turns out there was even more levels of indirection. I've updated the bug dependencies appropriately. Moving forward and backward describes best what we did during the past few days. This proposal here is not trying to solve the problem for everyone and every problem, instead I am trying to go a path where users that aren't affected by the problem won't see any differences in the future at all, and users that are facing this problem have a path out of it. At the time we started to look for solutions to this configuration problem in the EPP packages, the easiest way seemed to be the addition of some slf4j bundles, but until today I am not entirely sure that these are the only bundles that are missing. Maybe there is a package that included other optional bundles during build time and the p2 director de-installed them later on. The first problem that I see here is that my list of missing bundles is not necessarily complete. Then there is the problem of unknown side-effects. We *know* that there a lot of entries in the log file as soon as someone starts the Eclipse help. Other side-effects if these missing bundles are there? Probably not, but in the end it is unknown (at least to me). So that's another risk. And last: Why should we deliver SR1 packages with additional bundles just because there were problems in the former configuration of the release packages? So here are my proposed priorities. Other suggestions are welcome but that's how I would like to proceed with SR1: (1) We have to ensure that the SR1 (and in the future SR2) downloads of the EPP packages are clean and are shipped with the correct configuration. This goal can be achieved by using the latest p2 director application. (2) We are shipping the EPP packages with the same dependency structure that we had in the June release, that means that we *do not* include a special dependency to slf4j bundles, no change at all! The configuration error in the SR1 EPP packages doesn't appear in the new ones because we are using the new p2 director to create them. This has the advantage that we have clean SR1 packages and without any side effects caused by the additional loggers. (3) Updates from the Helios release in June: I expect that most updates just work and that the update process to SR1 is healing the wrong configuration (in this case this means that the additional bundles are in bundles.info *and* in the plugins directory - so yes, in that case they are there). (4) Then there is a *small fraction of users* running the Helios release packages in shared-install mode. They will run into problems and they will need education how to fix this. What we can provide them is a small feature that needs to be installed manually and includes the slf4j bundles. After this installation it should be safe to remove it again. Can we provide the education for (4) and are we willing not to provide a fully automated way from the release to the service release in case of (4)? To me it looks like the best solution because only the people who have the problem are required to take action. Thanks Markus, agree with your conclusion, and appreciate your deep dive into this to try and recover from the p2 bug. I've always thought p2 required/expected too much "perfection" with no way to recover or allow users to have control ... and seems this is another example of that. And, as others have said on mailing list, it would be good if some (all) of these scenarios could be better tested before we ship ... but ... to be honest, not sure who should be responsible for that. The package owners/maintainers are the obvious answer, but honestly, we would not even know the difference. Seems EPP packages (and whole idea of release train) would provide a great test bed for the p2 Team, that is being under utilized by them. There, I've said it. I've vented. I'm done with that. Maybe another concrete action is for someone to document all the various "update" scenarios that should be tested on various platforms, and include that with other generic testing procedures at http://wiki.eclipse.org/EPP/Package_Testing Any volunteers? I really do appreciate all the extra effort that has gone in to diagnosing, fixing, and educating everyone about this issue (especially the p2 team! :). (In reply to comment #22) > And, as others have said on mailing list, it would be good if some (all) of > these scenarios could be better tested before we ship ... but ... to be honest, > not sure who should be responsible for that. The package owners/maintainers are > the obvious answer, but honestly, we would not even know the difference. Seems > EPP packages (and whole idea of release train) would provide a great test bed > for the p2 Team, that is being under utilized by them. Hi, I'm not an Eclipse developer, so please forgive me for stepping in -- the technical aspects of this discussion are way beyond my jurisdiction ;-) But, as the reporter of bugs #315853, #317757, #287246 and #287122, I am following this closely, waiting for the day that I will finally be able to do shared installs on Linux "out of the box". As far as testing fo shared installs goes, IMHO a very simple test fails consistently on Linux: unpack official Eclipse tarball as root and try to install subclipse (any plugin?) as a regular user. I know David was not asking *what* could be tested, but instead *how* it could be tested by your QA. It's just that's very disappointing as the user to realize that such a "simple" (from our perspective) and necessary thing as installing basic plugins doesn't work on a brand new Eclipse version... Again, please, don't get me wrong, I understand by the amount of related bugs and developers involved that this is a complicated issue, and I do appreciate all the effort being put into solving this "the right way". My fingers are crossed ;-) (In reply to comment #23) Andre, thanks for chiming in and contributing to the discussion. It is important for eclipse developers (and everyone for that matter) to get of sense of how this affects the end user. Just to update you, we have (hopefully) fixed this for all new downloads now. I just downloaded a freshly built package, marked it Read-Only, started it, and installed some extra plug-ins. That seems to work well. :-). We are now focusing on the problem of starting with an Eclipse 3.6.0, updating to 3.6.1, and then adding extra plug-ins (remember, the update still uses the unfixed, 3.6.0 code). In the end, the bug that caused this whole mess might actually save us. For that particular installation, Markus noticed that the extra bundles come along for free. I will test that scenario tomorrow when I see Markus (right now I don't know the update site to use). So to summarize, the newly built EPP packages seem to be fine. With a little luck (we could use a little luck now), upgrades might work too -- and of course, this *just* affects shared install mode, regular (non-read only) are working fine. (In reply to comment #24) > I will test that scenario tomorrow when I > see Markus (right now I don't know the update site to use). The latest p2 metadata should be available from this location: http://download.eclipse.org/technology/epp/packages/helios/SR1.233 (This is only a temporary location and will be removed in a few days or when we release the final Helios SR1 packages.) (In reply to comment #24) > (In reply to comment #23) > Andre, thanks for chiming in and contributing to the discussion. It is > important for eclipse developers (and everyone for that matter) to get of sense > of how this affects the end user. My pleasure. And thank you guys for all the hard work. > Just to update you, we have (hopefully) fixed this for all new downloads now. I > just downloaded a freshly built package, marked it Read-Only, started it, and > installed some extra plug-ins. That seems to work well. :-). Nice! =) > We are now focusing on the problem of starting with an Eclipse 3.6.0, updating > to 3.6.1, and then adding extra plug-ins (remember, the update still uses the > unfixed, 3.6.0 code). Mmmh... indeed. > So to summarize, the newly built EPP packages seem to be fine. That sounds good. So, if I got this right, when 3.6.1 packages are officially released, if I just install from scratch using the official tarballs (instead of upgrading a 3.6.0 installation) it should just work? If you guys want me to test one of this packages before they go gold, I'll be more than happy to help, just point me the right direction. (In reply to comment #26) > That sounds good. So, if I got this right, when 3.6.1 packages are officially > released, if I just install from scratch using the official tarballs (instead > of upgrading a 3.6.0 installation) it should just work? > Yep :-) > If you guys want me to test one of this packages before they go gold, I'll be > more than happy to help, just point me the right direction. Here is the one I tested last night [1]. As you can imagine, it takes a long time to build every configuration for every platform, so this build is just a single package. But it does have all the platforms, so feel free to try it and let us know how it works. [1] http://build.eclipse.org/technology/epp/epp_build/36/download/20100913-1233/ Also, this is just a temp build, so it will be going away (nothing official yet). *** Bug 322056 has been marked as a duplicate of this bug. *** *** Bug 322158 has been marked as a duplicate of this bug. *** (In reply to comment #22) > > Maybe another concrete action is for someone to document all the various > "update" scenarios that should be tested on various platforms, and include that > with other generic testing procedures at > http://wiki.eclipse.org/EPP/Package_Testing > Any volunteers? > I added the following generic text to the generic test procedure ... but, if anyone can make more specific, please do. = = = = Test Shared Installs On some OSes (traditionally Linux, but installing into Windows 7 "Programs" is similar) it is expected to be able to install Eclipse as administrator and then be used by several users, where each user can make their own additions, preferences, projects, etc. For some history that emphasizes the importance of testing shared installs, see bug 322929. * In addition to the normal "single user" tests above, install the package as "root" (or Administrator) and then, as a regular "user", repeat many of the single users tests: install additional features from site repository, set your own preferences, create projects, etc. = = = = = = FYI, in my small test of a shared install, there were no "software repository sites" pre-populated in the list of software sites (when using as non-administrator user). I assume that's normal, working as designed, but if not, let me know and I'll open a new bug for that. (In reply to comment #30) > > FYI, in my small test of a shared install, there were no "software repository > sites" pre-populated in the list of software sites (when using as > non-administrator user). I assume that's normal, working as designed, but if > not, let me know and I'll open a new bug for that. I noticed that too, and I'm not sure if that's by design. (I understand why it's happening, but I don't know if that's a bug or a feature). Feel free to open a bug and we can discuss that there. But I have to say, if that's the biggest problem we have right now, then I'm very happy :-). (In reply to comment #30) > ... > FYI, in my small test of a shared install, there were no "software repository > sites" pre-populated in the list of software sites (when using as > non-administrator user). I assume that's normal, working as designed, but if > not, let me know and I'll open a new bug for that. I voted this bug because I tried 4 buggy installations till I noticed that only installing in a user folder (so a "non-shared installation") stopped problems retated to this bug. In all of the buggy installations the first thing I noticed was that one you say. The "non-shared" installation showed from the beginning that list correctly populated instead. (In reply to comment #31) > (In reply to comment #30) > ... > I noticed that too, and I'm not sure if that's by design. (I understand why > it's happening, but I don't know if that's a bug or a feature). Feel free to > open a bug and we can discuss that there. Ok. Just to cross reference, I opened bug 325463. (I saw with plain 'ol eclipse also, not just EPP package, so assume it is not EPP bug). FYI: The latest p2 repository with the package definitions is available from http://download.eclipse.org/technology/epp/packages/helios/SR1.246 Packages based on this repository are being build and copied to http://build.eclipse.org/technology/epp/epp_build/36/download/20100917-0715/ I've tested a few scenarios: 0. Install Helios for Java Developers (SR0) in read only mode, install an extra plug-in (Memory analyzer), and watch it FAIL! (i.e. this bug). 1. Install Helios for Java Developers (SR0) in read only mode. Upgrade to SR1 (sudo ./eclipse then upgrade). Install an extra plug-in (Memory Analyzer). SUCCESS! 2. Install (download) Helios for Java Developers (SR1). Marks as read only. Install an extra plug-in (Memory Analyzer). SUCCESS! The only workflow that doesn't work is setting up a shared install. Installing some local bundles, and then upgrading the base. In this case, you need to re-install the local bundles. But that's a whole other can of worms. I would like to declare success on this bug for Helios SR1. Thanks to Pascal and Daniel for actually fixing this bug. To David for coordinating things and to Markus for following all my ramblings as we tried to track this down. This bug caused some grief for a number of users, so I'm sorry for any inconvenience. Hi, I just wanted to confirm that Helios SR1 installed as root on Linux (finally!) allows plugin installations by regular users :-D This is really big news for Linux users, because now it means Eclipse can be installed only once by root and used by any user. (on our setup here it also means avoiding NFS installs). So, thank you guys for finally fixing this =) PS: I'm sorry I couldn't test it as promised before 3.6.1 officially came out, things got kind of hectic around here lately... That's really good news! Thanks for testing it. hey, just to clarify. This bug is about enabling regular users to install new stuff in shared-mode Eclipse, and it's NOT about regular users making update of stuff installed in shared-mode, yes? Has any progress been made on a workaround for 3.6.0, or is an reinstall of 3.6.1 the only viable solution? (In reply to comment #39) > Has any progress been made on a workaround for 3.6.0, or is an reinstall of > 3.6.1 the only viable solution? Update to Helios SR1 / platform 3.6.1 is expected to work as well. As bug 320153 was re-opened, I'm not sure whether this one should stay resolved/fixed. (In reply to comment #40) > (In reply to comment #39) > > Has any progress been made on a workaround for 3.6.0, or is an reinstall of > > 3.6.1 the only viable solution? > > Update to Helios SR1 / platform 3.6.1 is expected to work as well. *** Bug 320153 has been marked as a duplicate of this bug. *** |