Bugzilla – Full Text Bug Listing
| Summary: | Conflicting dependency when running Check for Updates immediately on a clean install of Helios SR2 | ||
|---|---|---|---|
| Product: | [Technology] EPP | Reporter: | Gerald O'Sullivan <gsosullivan> |
| Component: | Packager | Assignee: | Project Inbox <epp.packager-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | david_williams, jonah, mknauer, remy.suen, supaphr33k |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Gerald O'Sullivan
If you just installed a Helios SR2 package, then search for updates shouldn't find anything because that is the most recent version. Seems wrong that EPP package has something newer in their repository than in their SR2 build. My guess is this is a variant of bug 339659 (and others) ... where "shared installs" a) are tricky, and b) do not give very good error messages. To document it, the most recent "jee epp feature" (and product) in helios SR2 repo and in jee package is org.eclipse.epp.package.jee.feature_1.3.2.20110218-0812 That's what you should see in your /usr/local/eclipse/features directory. So, I think the question is why does it think you have an older version installed? version 1.3.2.20110218-0812? Possibly from a stale profile in ~/.eclipse? So, it would help, in this case, if you clarified how you "cleaned out all traces of old Eclipse installs". In particular, did you remove the ~/.eclipse directory? Also, it would help in reports such as this, to know for sure what userIDs you used for each part of the installs. I assume the tar extract to /usr/local/ was done as "root"? And the "update" done as your own individual id? That is, a true shared install? Thanks in advance for the additional information/confirmations. (In reply to comment #2) Part of my comment was wrong ... in two ways, first a copy/paste error ... > > To document it, the most recent "jee epp feature" (and product) in helios SR2 > repo and in jee package is > > org.eclipse.epp.package.jee.feature_1.3.2.20110218-0812 > I meant to paste one with a version of "1.3.2.20110301-1807" which is latest in the repository. But secondly, now that I've re-looked at some freshly downloaded zips, the version that is in those is in fact 1.3.2.20110218-0812 (what I originally pasted). I have some existing installs with the "0301" version ... but not sure where those came from (and they were not shared installs). So, the bug is valid. And, if fact, I've been able to reproduce it. I am moving to the general "packager" component, since doesn't seem specific to Java EE, but, as originally reported: "The same thing happens with the plain vanilla Eclipse IDE for Java Developers". (I didn't try to reproduce that, but would assume its the same issue). Markus ... was the EPP repo re-created "late", after the February release? ... on 0301 for some other reason? From looking at the repos under .../technology/epp/packages/helios it appears there were several repos produced after the packages were produced on 0218 (I'm picking 02/18 not only from feature version in the package, but also the "build date" on the last helios sr2 build listed at http://www.eclipse.org/epp/download.php) drwxrwsr-x+ 4 mknauer technology.packaging 1K 2011-03-01 14:27 SR2/ drwxrwsr-x+ 5 mknauer technology.packaging 1K 2011-02-11 00:32 SR2.266/ drwxrwsr-x+ 4 mknauer technology.packaging 1K 2011-02-13 11:51 SR2.271/ drwxrwsr-x+ 4 mknauer technology.packaging 1K 2011-02-18 04:14 SR2.280/ drwxrwsr-x+ 4 mknauer technology.packaging 1K 2011-03-01 14:27 SR2.282/ drwxrwsr-x+ 4 mknauer technology.packaging 1K 2011-02-25 05:11 SR2.buggy/ drwxrwsr-x+ 4 mknauer technology.packaging 1K 2011-02-27 07:17 SR2.fixed/ If I try and "manually" use the direct repos, instead of the composites, these work as expected (i.e. no updates found) http://download.eclipse.org/technology/epp/packages/helios/SR2.280 http://download.eclipse.org/releases/helios/201102250900/ but these do not (i.e. find a more recent version, that can't be installed) http://download.eclipse.org/technology/epp/packages/helios/SR2.282 http://download.eclipse.org/releases/helios/201102250900/ So ... Markus ... one obvious suggestion is to revert your composite back to SR2.280 ... but, you obviously produced SR2.282 for a reason, and I'm not sure what that repo was supposed to fix. Good luck. :) Looking into this now...
The naming scheme of the directories is
[R|SR1|SR2].nnn (where nnn is the Hudson build number)
About the different builds and p2 repositories:
/SR2.280 used for the Helios SR2 package build
/SR2.buggy same as SR2.280 but with download stats enabled
in artifacts.xml; this one was online for a short period
until we found the Mac OSX update problem
/SR2.fixed same as /SR2.buggy but with a manual modification of the
p2 metadata that fixed the Mac problem, see bug 338310
/SR2 == /SR2.282 (identical content, see readme.txt in the directories)
bug 338310#c30
The scenario that you describe here (download SR2 JEE, check for updates) was tested on Linux (64 bit and 32 bit).
(In reply to comment #1) > If you just installed a Helios SR2 package, then search for updates shouldn't > find anything because that is the most recent version. Seems wrong that EPP > package has something newer in their repository than in their SR2 build. See bug 338310 comment #38 - it updates the package feature IU. (In reply to comment #5) > So ... Markus ... one obvious suggestion is to revert your composite back to > SR2.280 ... but, you obviously produced SR2.282 for a reason, and I'm not sure > what that repo was supposed to fix. Going back to SR2.280 is not possible as it would break all Mac OSX installations out there. >
> Going back to SR2.280 is not possible as it would break all Mac OSX
> installations out there.
Yeah, realized that shortly after I wrote it. Plus, I discovered that in a non-shared install ... someone can easily update to the 0301 version, so it is definitely "out there in the wild".
I also discovered that the SR2 "shared install" can be "updated" to 0301 version, by root (or, of course for Ubuntu, using sudo). It might be "required" for admins to do this? To have a more consistent install? Such as for them, or users, to do future updates?
This would be a "work around" of course, and we should still strive to understand the root problem, and prevent it from happening in future.
We might also want to add some "udpate tests" to Indigo tests ... for example, can someone with a 0218 shared install update, or must they first update to 0301 version and then update to Indigo?
Adding -Declipse.p2.mirrors=false argument to eclipse.ini will fix the "fresh install fails on Check for updates" bug. I shall leave it to someone else to explain why, but I think someone sacrificed all Windows installs on the altar of Macintosh. (In reply to comment #9) > Adding -Declipse.p2.mirrors=false argument to eclipse.ini will fix the "fresh > install fails on Check for updates" bug. > This really seems like this should not be the case ... can you explain a bit more exactly what you mean? Exactly what steps? And, in general, we do not advise people to use eclipse.p2.mirrors=false all the time ... only to solve a specific short term problem. (In reply to comment #10) > (In reply to comment #9) > > Adding -Declipse.p2.mirrors=false argument to eclipse.ini will fix the "fresh > > install fails on Check for updates" bug. > > > > This really seems like this should not be the case ... can you explain a bit > more exactly what you mean? Exactly what steps? And, in general, we do not > advise people to use eclipse.p2.mirrors=false all the time ... only to solve a > specific short term problem. Fresh install of Helios. Select "Check for updates" and it fails with the error message in the original post of this thread. Adding that VM argument fixes the error and allows Check for updates to complete successfully. I tried it after reading this comment on another bug post: https://bugs.eclipse.org/bugs/show_bug.cgi?id=338310#c33 > > Fresh install of Helios. Select "Check for updates" and it fails with the > error message in the original post of this thread. Adding that VM argument > fixes the error and allows Check for updates to complete successfully. > I could not duplicate your success. You may been hitting some other bug? Are you on a Mac? As bug 338310 was about Macs? I tried reproducing on Linux. Just to document my exact steps ... Using sudo I freshly installed eclipse-jee-helios-SR2-linux-gtk-x86_64.tar.gz into /usr/local/ from another non-sudo window ran that version eclipse, with fresh workspace, and confirmed that "check for updates" found an udpate, but could not install it due to conflicts From sudo windows, updated the eclipse.ini in /usr/local/eclipse, putting -Declipse.p2.mirrors=false at the very end, after other -vmargs. when back to non-sudo, ran that shared version of eclipse again, tried "check for updates", and again found updates that could not be installed due to conflicts. See any mistakes in my steps? If not, I wanted to document this in detail, so others would not be thrown off by a work around that didn't work. Similarly, you might be experiencing a different bug, that might deserve a separate report. Or ... just suggesting ... just guessing ... I wonder if while, or after, editing eclipse.ini you left things in "sudo mode" in which case it would have worked simply because you had write access to the shared instance? If so, that would have been the work around mentioned in comment #8. That is a better work around, since doesn't level mirrors disabled. But, if you are on a Mac, experiencing a different bug ... I'll won't be able to help directly, since I don't have a Mac. Hope this helps, you and others. (In reply to comment #12) > > > > Fresh install of Helios. Select "Check for updates" and it fails with the > > error message in the original post of this thread. Adding that VM argument > > fixes the error and allows Check for updates to complete successfully. > > > > I could not duplicate your success. You may been hitting some other bug? Are > you on a Mac? As bug 338310 was about Macs? I tried reproducing on Linux. Just > to document my exact steps ... > > Using sudo > I freshly installed eclipse-jee-helios-SR2-linux-gtk-x86_64.tar.gz into > /usr/local/ > > from another non-sudo window ran that version eclipse, with fresh workspace, > and confirmed that "check for updates" found an udpate, but could not install > it due to conflicts > > From sudo windows, updated the eclipse.ini in /usr/local/eclipse, putting > -Declipse.p2.mirrors=false at the very end, after other -vmargs. > > when back to non-sudo, ran that shared version of eclipse again, tried "check > for updates", and again found updates that could not be installed due to > conflicts. > > See any mistakes in my steps? > > If not, I wanted to document this in detail, so others would not be thrown off > by a work around that didn't work. > > Similarly, you might be experiencing a different bug, that might deserve a > separate report. > > Or ... just suggesting ... just guessing ... I wonder if while, or after, > editing eclipse.ini you left things in "sudo mode" in which case it would have > worked simply because you had write access to the shared instance? If so, that > would have been the work around mentioned in comment #8. That is a better work > around, since doesn't level mirrors disabled. > > But, if you are on a Mac, experiencing a different bug ... I'll won't be able > to help directly, since I don't have a Mac. > > Hope this helps, you and others. I am actually running Windows XP with an admin account, sorry for the confusion. The EPP project does not have its "own" Packager anymore. EPP uses other technologies, such as Eclipse Tycho, Maven and Eclipse PDE. Therefore any remaining bugs are now being closed as WONTFIX. If this bug is still relevant, please make a comment and we'll move it to the correct project/component for further investigation. This change was made as part of a bulk change. |