Community
Participate
Working Groups
Build Identifier: I20100520-1744 I downloaded the RC2 SDK and tried to install all from Helios except the RT parts. Reproducible: Always Steps to Reproduce: 1. Download eclipse-SDK-3.6RC2-linux-gtk-x86_64.tar.gz 2. Freshly install the SDK (cd /opt2/linux/x86_64/; rm -rf eclipse-3.6; tar -xf /opt2/tars/eclipse/3.6/eclipse-SDK-3.6RC2-linux-gtk-x86_64.tar.gz; mv -v eclipse eclipse-3.6) 3. Try to install all (except the RT parts) from HELIOS update site.
Created attachment 169731 [details] The console log from the attempted install
Created attachment 169732 [details] Screenshot of the error
Cannot complete the install because of a conflicting dependency. Software being installed: Sequoyah Feature 0.5.0.I20100316-1200_incubation (org.eclipse.sequoyah.feature.feature.group 0.5.0.I20100316-1200_incubation) Software being installed: Sequoyah VNC Viewer Runtime 1.0.0.I20100519-0417 (org.eclipse.sequoyah.vnc.feature.feature.group 1.0.0.I20100519-0417) Only one of the following can be installed at once: Sequoyah VNC Views (Incubation) 0.5.0.I20100316-1200_incubation (org.eclipse.sequoyah.vnc.vncviewer.vncviews 0.5.0.I20100316-1200_incubation) Sequoyah VNC Views 1.0.0.I20100519-0417 (org.eclipse.sequoyah.vnc.vncviewer.vncviews 1.0.0.I20100519-0417) Cannot satisfy dependency: From: Sequoyah Feature 0.5.0.I20100316-1200_incubation (org.eclipse.sequoyah.feature.feature.group 0.5.0.I20100316-1200_incubation) To: org.eclipse.sequoyah.vnc.feature.feature.group [0.5.0.I20100316-1200_incubation] Cannot satisfy dependency: From: Sequoyah VNC Viewer Runtime (Incubation) 0.5.0.I20100316-1200_incubation (org.eclipse.sequoyah.vnc.feature.feature.group 0.5.0.I20100316-1200_incubation) To: org.eclipse.sequoyah.vnc.vncviewer.vncviews [0.5.0.I20100316-1200_incubation] Cannot satisfy dependency: From: Sequoyah VNC Viewer Runtime 1.0.0.I20100519-0417 (org.eclipse.sequoyah.vnc.feature.feature.group 1.0.0.I20100519-0417) To: org.eclipse.sequoyah.vnc.vncviewer.vncviews [1.0.0.I20100519-0417] If I go and disable the offending feature (sequoyah) I get a new failure: Cannot complete the install because of a conflicting dependency. Software being installed: XSD - XML Schema Definition SDK 2.6.0.v20100517-0323 (org.eclipse.xsd.sdk.feature.group 2.6.0.v20100517-0323) Only one of the following can be installed at once: XSD Edit 2.6.0.v20100511-1620 (org.eclipse.xsd.edit 2.6.0.v20100511-1620) XSD Edit 2.5.0.v20100427-1557 (org.eclipse.xsd.edit 2.5.0.v20100427-1557) Cannot satisfy dependency: From: XSD Sample Editor 2.6.0.v20100427-1557 (org.eclipse.xsd.editor 2.6.0.v20100427-1557) To: bundle org.eclipse.xsd.edit [2.5.0,2.6.0) Cannot satisfy dependency: From: XSD - XML Schema Definition SDK 2.6.0.v20100517-0323 (org.eclipse.xsd.sdk.feature.group 2.6.0.v20100517-0323) To: org.eclipse.xsd.edit [2.6.0,2.7.0) Cannot satisfy dependency: From: XSD - XML Schema Definition SDK 2.6.0.v20100517-0323 (org.eclipse.xsd.sdk.feature.group 2.6.0.v20100517-0323) To: org.eclipse.xsd.editor [2.6.0,2.7.0) And if I disable that one (XSD) I get yet another one: Cannot complete the install because of a conflicting dependency. Software being installed: EPP Pulsar Feature 1.3.0.20100521-0437 (org.eclipse.epp.package.pulsar.feature.feature.group 1.3.0.20100521-0437) Software currently installed: Eclipse SDK 3.6.0.I20100520-1744 (org.eclipse.sdk.ide 3.6.0.I20100520-1744) Only one of the following can be installed at once: Eclipse Workbench User Guide 3.6.0.v20100425-2000 (org.eclipse.platform.doc.user 3.6.0.v20100425-2000) Eclipse Workbench User Guide 3.6.0.v20100520-0800 (org.eclipse.platform.doc.user 3.6.0.v20100520-0800) Eclipse Workbench User Guide 3.6.0.v20100513-0800 (org.eclipse.platform.doc.user 3.6.0.v20100513-0800) Cannot satisfy dependency: From: EPP Pulsar Feature 1.3.0.20100521-0437 (org.eclipse.epp.package.pulsar.feature.feature.group 1.3.0.20100521-0437) To: org.eclipse.platform.feature.group [3.6.0.v20100512-9gF78GpqFsgprEYh7z-Q7acirDtvcwz-ebYa] Cannot satisfy dependency: From: Eclipse Platform 3.6.0.v20100512-9gF78GpqFsgprEYh7z-Q7acirDtvcwz-ebYa (org.eclipse.platform.feature.group 3.6.0.v20100512-9gF78GpqFsgprEYh7z-Q7acirDtvcwz-ebYa) To: org.eclipse.platform.doc.user [3.6.0.v20100513-0800] Cannot satisfy dependency: From: Eclipse Platform 3.6.0.v20100512-9gF78GpqFt6trMPh89Rz-jmqnMYpK-UpioD (org.eclipse.platform.feature.group 3.6.0.v20100512-9gF78GpqFt6trMPh89Rz-jmqnMYpK-UpioD) To: org.eclipse.platform.doc.user [3.6.0.v20100520-0800] Cannot satisfy dependency: From: Eclipse Project SDK 3.6.0.v20100427-7Q7m-DPY2bP2OAHoN3Clxeoiz0mqprBknKqFPV3E-oIMi (org.eclipse.sdk.feature.group 3.6.0.v20100427-7Q7m-DPY2bP2OAHoN3Clxeoiz0mqprBknKqFPV3E-oIMi) To: org.eclipse.platform.feature.group [3.6.0.v20100512-9gF78GpqFt6trMPh89Rz-jmqnMYpK-UpioD] Cannot satisfy dependency: From: Eclipse SDK 3.6.0.I20100520-1744 (org.eclipse.sdk.ide 3.6.0.I20100520-1744) To: org.eclipse.sdk.feature.group [3.6.0.v20100427-7Q7m-DPY2bP2OAHoN3Clxeoiz0mqprBknKqFPV3E-oIMi] That's when I stopped. I thought that these kind of problems should be fixed before a release candidate was released. How can the general public start testing the release candidates if they don't even install?
Created attachment 169735 [details] Updated console log from the attempted install
I think this is related to the fact that Helios is a composite that contains older milestones. In essence, that means that no feature can ever be removed from Helios. Judging from the qualifier timestamp, the feature: org.eclipse.sequoyah.feature.feature.group 0.5.0.I20100316-1200_incubation was added some time ago. It doesn't appear to have a successor. That, in combination with fairly strict version ranges, creates a conflict when you try to install everything. In general, I think we have a clash of two ways of viewing the Helios repository. One one hand, it should be easy to use for the end user. On the other, it should contain everything that has ever been published. The latter puts quite a strain on the end user since it's now his responsibility to deselect old versions of things that no longer works in a mix with newer material. Another consequence is that since the repositories just keep growing, they get more and more sluggish to work with. If I'm right in my assumption, your update will be successful if you change to use the latest milestone (RC1) that was added to Helios instead of the composite. You can do that by using this URL: http://download.eclipse.org/releases/helios/201005210900/
Please change the product/component if I mis-categorized this bug.
(In reply to comment #5) > If I'm right in my assumption, your update will be successful if you change to > use the latest milestone (RC1) that was added to Helios instead of the > composite. You can do that by using this URL: > > http://download.eclipse.org/releases/helios/201005210900/ I can try that, but how is an end user supposed to know that they need to use another than the "official" repository? I also recommended that the simple "go and install all except RT" use case should be done by the releng team. I assume that it has not been not done, as otherwise the breakage would have been detected earlier.
(In reply to comment #5) > I think this is related to the fact that Helios is a composite that contains > older milestones. In essence, that means that no feature can ever be removed > from Helios. Given the fact that Helios has not even been released that's quite a surprise. I would expect the release of Helios to contain the "first" set of plugins for the Helios lifetime. Later Helios 3.6.x releases might contribute to the repo, but they should not break it.
(In reply to comment #8) > Given the fact that Helios has not even been released that's quite a surprise. > I would expect the release of Helios to contain the "first" set of plugins for > the Helios lifetime. Later Helios 3.6.x releases might contribute to the repo, > but they should not break it. I agree. That's the way I would expect things to be too being a normal consumer. (In reply to comment #7) > I can try that, but how is an end user supposed to know that they need to use > another than the "official" repository? > This repository is not in any way published as things stands today so the end user cannot know this. > I also recommended that the simple "go and install all except RT" use case > should be done by the releng team. I assume that it has not been not done, as > otherwise the breakage would have been detected earlier. As I said earlier, the strain is moved to the end user and breakages like this are to be expected when we use a composite. In essence, the use-case you mention can no longer be considered valid. I'm not saying that this is a good thing. Personally, I think it's indeed unfortunate. (In reply to comment #6) > Please change the product/component if I mis-categorized this bug. Not sure how to categorize this actually. p2 does what it's supposed to do. It refuses to install a conflicting dependency. But I would still consider this a p2 problem because one of the reasons for keeping the older repositories around is that p2 needs them in order to rollback to a previous installation. If that wasn't necessary then I think it would make more sense to just publish the latest milestone. It's free of conflicts and much smaller (faster). The composite could be published too of course, but not as the repository fronted to the end user. It could have an alternative URL and would be more suitable for build engineers.
(In reply to comment #9) > As I said earlier, the strain is moved to the end user and breakages like this > are to be expected when we use a composite. In essence, the use-case you > mention can no longer be considered valid. I'm not saying that this is a good > thing. Personally, I think it's indeed unfortunate. I think from an end users point of view the claim I want to intstall all (or a large set) of what is offered is a very valid use case, as the user can not know about the interdependency problems. That's one of the reasons 2p exists in the first place. To take the burden of knowing all the interdependencies off the user. > (In reply to comment #6) > > Please change the product/component if I mis-categorized this bug. > > Not sure how to categorize this actually. p2 does what it's supposed to do. It > refuses to install a conflicting dependency. But I would still consider this a > p2 problem because one of the reasons for keeping the older repositories around > is that p2 needs them in order to rollback to a previous installation. If that > wasn't necessary then I think it would make more sense to just publish the > latest milestone. It's free of conflicts and much smaller (faster). > > The composite could be published too of course, but not as the repository > fronted to the end user. It could have an alternative URL and would be more > suitable for build engineers. I think if that could be done it sounds like the best solution for the end users and build engineers. How feasible is it to get that for the release? I fear if we don't have it lot's of users that install a large part of Helios will otherwise hit the same snag that I just did.
(In reply to comment #10) > > Not sure how to categorize this actually. p2 does what it's supposed to do. It > > refuses to install a conflicting dependency. But I would still consider this a > > p2 problem because one of the reasons for keeping the older repositories around > > is that p2 needs them in order to rollback to a previous installation. If that > > wasn't necessary then I think it would make more sense to just publish the > > latest milestone. It's free of conflicts and much smaller (faster). > > > > The composite could be published too of course, but not as the repository > > fronted to the end user. It could have an alternative URL and would be more > > suitable for build engineers. > > I think if that could be done it sounds like the best solution for the end > users and build engineers. > > How feasible is it to get that for the release? I fear if we don't have it > lot's of users that install a large part of Helios will otherwise hit the same > snag that I just did. That might just be the main question that needs an answer (quickly). So I'm moving this to cross-project for further discussion.
What's the question? The /releases/helios repository is RC1. So is this bug simply stating that not everything in RC1 can be installed with RC2 platform as the starting point? Is the same problem encountered if starting with RC1 platform? That'd be more surprising. Sorry if that's what you are saying and I've just missed it.
> I also recommended that the simple "go and install all except RT" use case > should be done by the releng team. I assume that it has not been not done, as > otherwise the breakage would have been detected earlier. There is no releng team. Or, else you could say we are all the releng team. I don't think the reason for the composite repositories has been explained well. We do the composites not specifically to test having multiples. So, if you've found a bug with that, that's great. Well, frustrating, I'm sure, but better we find bugs now, when they could be fixed, rather than during a service release when it would be too late.
Just FYI, using the repository mentioned in comment #5 does indeed work.
(In reply to comment #13) > > I also recommended that the simple "go and install all except RT" use case > > should be done by the releng team. I assume that it has not been not done, as > > otherwise the breakage would have been detected earlier. > > There is no releng team. Or, else you could say we are all the releng team. > > I don't think the reason for the composite repositories has been explained > well. We do the composites not specifically to test having multiples. So, if > you've found a bug with that, that's great. Well, frustrating, I'm sure, but > better we find bugs now, when they could be fixed, rather than during a service > release when it would be too late. Well if I found the problem in time for the Helios release to be fixed, great, wonderful. I am just worried about the fact that that this already RC2 and a fix for the release might no longer be possible.
I tried starting with RC1, and saw only one "conflicting dependencies" error (pasted below) related to GMF. I think this error is because GMF did a refactor so, yes, probably has some "old" no-longer-relevant feature show up as "most recent" in some category, where it no longer is. (I think the problems seen with original report, starting with RC2 platform, also introduces the error of "can not satisfy" dependencies, as well as the conflicting dependencies. The "can not satisfy" may be the result of overly tight version ranges ... which could be another bug/request against each project that does that ... but hard to know if its really a bug, or they really need those tight ranges (probably a bad practice, I'm just saying I don't know). So, I've retitled this bug ... now that I think I understand it. If I've misunderstood, let me know. So, one "fix" is just to make sure we have _exactly_ same features from release, to service release. That's what we are supposed to do. But, in general that's pretty limiting. I'm not sure what a solution might be, though. On client side, I think it'd need some concept of "most recent" category, and only show those (and currently categories are not "time stamped", as far as I know? The are intentionally merged, if "version" is different). On repository side, we could (in theory) have a practice of only including "categories" from most recent sub-repository, and "disconnect" the older ones. (The old features, etc., would still be installable, or could rollback to them, but just not selected via a category). Is that limiting? For the specific GMF issue below, there might be other solutions. I know one of the "promises" of p2 is that is shouldn't really matter ... a solution will be found if things defined right. So, perhaps if there is some conflict, its a sign of some other, project specific way that features are defined or combined? So ... yes, a problem that is hard to "fix". I know in the past we've had problems supporting the "select all" scenario ... and seems like we will this release too. But, thanks for reporting, and testing. = = = = = = = = = = Cannot complete the install because of a conflicting dependency. Software being installed: Graphical Modeling Framework Examples 1.4.0.v20100428-2359-7B7H8_F8NcJLZJvMm9THaJ (org.eclipse.gmf.examples.feature.group 1.4.0.v20100428-2359-7B7H8_F8NcJLZJvMm9THaJ) Software being installed: Graphical Modeling Framework Runtime Examples 1.4.0.v20100511-1355-7B7L0F8NcJP-JxPc9U1oc (org.eclipse.gmf.examples.runtime.feature.group 1.4.0.v20100511-1355-7B7L0F8NcJP-JxPc9U1oc) Only one of the following can be installed at once: GMF Clipboard Support Example Plug-in 1.2.0.v20100511-1355 (org.eclipse.gmf.examples.runtime.emf.clipboard 1.2.0.v20100511-1355) GMF Clipboard Support Example Plug-in 1.2.0.v20090403-1720 (org.eclipse.gmf.examples.runtime.emf.clipboard 1.2.0.v20090403-1720) Cannot satisfy dependency: From: Graphical Modeling Framework Examples 1.4.0.v20100428-2359-7B7H8_F8NcJLZJvMm9THaJ (org.eclipse.gmf.examples.feature.group 1.4.0.v20100428-2359-7B7H8_F8NcJLZJvMm9THaJ) To: org.eclipse.gmf.examples.runtime.emf.clipboard [1.2.0.v20090403-1720] Cannot satisfy dependency: From: Graphical Modeling Framework Runtime Examples 1.4.0.v20100511-1355-7B7L0F8NcJP-JxPc9U1oc (org.eclipse.gmf.examples.runtime.feature.group 1.4.0.v20100511-1355-7B7L0F8NcJP-JxPc9U1oc) To: org.eclipse.gmf.examples.runtime.emf.clipboard [1.2.0.v20100511-1355]
(In reply to comment #16) > I tried starting with RC1, and saw only one "conflicting dependencies" error > (pasted below) related to GMF. Beware, as you can see in Comment #3 I also saw only "one" "conflicting dependencies" error, but when I tried to "fix" it another showed up, ...
I'm sorry, but it doesn't matter one bit that there was an initial confusion regarding RC1 or RC2. The *current* Helios release is inconsistent and the primary problem remains, nameley: *Nothing can ever be removed from the Helios repository* We have a fundamental error in how we publish Helios. At least if we want to support: 1. Only relevant features should be presented to the user. 2. Everything but RT should be installable together. That's simply not true. The culprit vnc feature is indeed the latest version. The problem is that in later milestones, this feature no longer exists. That however, doesn't make it go away (of course) since the repository is a composite where everything is first merged and then the latest version shown. So I'm changing the title again to reflect the real problem.
Sorry, the culprit feature is not vnc. It's what I stated before: org.eclipse.sequoyah.feature.feature.group 0.5.0.I20100316-1200_incubation
Is the fundamental problem here that the helios repository contains multiple milestones? If so, it will be fixed since before we release all older content will surely be removed. Thomas, is there some other fundamental error in our build that I'm missing? Are you concerned about the same kind of problem when merging RC0 and RC1 content later on? I agree that would be a problem if a project participated in RC0 but did not participate in RC1.
(In reply to comment #20) > Thomas, is there some other fundamental error in our build that I'm missing? > Are you concerned about the same kind of problem when merging RC0 and RC1 > content later on? I agree that would be a problem if a project participated in > RC0 but did not participate in RC1. Projects that don't participate or a decision from a project to package things differently, it's the same problem really. The obsoleted features will remain forever and we have no mechanism to remove them. Perhaps we don't want to remove them to keep the rollback to previous install path open for all possible cases but if that's our intention, then I think it's essential that we somehow add a way to make old obsolete content invisible for new installs. I'm far from convinced that ever growing composites is the right way to go. It takes longer and longer to download, it's more vulnerable for network errors, the planning time increases, and memory consumption is already problematic. The data needs to be there, sure. But does it need to be what the user encounters first hand? Could the composite be consulted on demand and only when it's absolutely necessary?
Good morning all, We from Sequoyah have decided to remove the org.eclipse.sequoyah.feature from the 1.0.0 version, since it was only a container feature that we used to build our product. When we were testing the M7 repository, we saw that both container and individual features showed up for the user, which could lead to some confusion. This way we can think of 2 ways to fix this, from our side: 1) We could try to create and "old" build, using the timestamp for the previous builds and re-add the container feature, or 2) The 0.5.0 could be definitely removed from the current repository, as we understand from Comment #20. This wouldn't be a problem because we don't have any project/product that depends on this specific version. They should all depend on Sequoyah 1.0.0. If you suggest any other solution, we are willing to discuss it and work to fix it ASAP. Thanks, Daniel Pastore
So currently we have this big huge Helios composite repo at http://download.eclipse.org/releases/helios. What would stop us in the future (and I believe its too late for Helios) to switch to a pattern were all Milestones and RCs are seperate as in http://download.eclipse.org/releases/helios/M7 http://download.eclipse.org/releases/helios/RC1 and so on ? Still people could address old content by adding this to their list of software sites. If they dont, they only get to see to new and cool stuff ? - christian
(In reply to comment #22) > Good morning all, > > We from Sequoyah have decided to remove the org.eclipse.sequoyah.feature from > the 1.0.0 version, since it was only a container feature that we used to build > our product. When we were testing the M7 repository, we saw that both container > and individual features showed up for the user, which could lead to some > confusion. > > This way we can think of 2 ways to fix this, from our side: > Thanks, Daniel. No need for you to "fix" anything in current repository. Just get settled on what your content is (I think you have, right?) And, yes, sounds right to not deliver a "container feature" if it is intended only to direct the build.
(In reply to comment #23) > What would stop us in the future (and I believe its too late for Helios) to > switch to a pattern were all Milestones and RCs are seperate as in > http://download.eclipse.org/releases/helios/M7 > http://download.eclipse.org/releases/helios/RC1 and so on ? > > Still people could address old content by adding this to their list of software > sites. If they dont, they only get to see to new and cool stuff ? That is exactly what we are doing. There is a separate repository for each milestone or release that can be addressed individually. The parent repository is just an aggregator that points to all the child repositories. So all these use cases will be supported with the current structure - see everything, see only new contents, etc. In the end I don't think the "select all, install everything" use case is particularly interesting for the Helios repository. Other than testing I'm not sure why a user would want to do this. It should certainly work for the initial release when everything is consistent, but if projects don't contribute to RC1 or change their feature structure in incompatible ways (which they shouldn't be doing), then it's just not going to work.
[repeating some of what John said ... since we were typing at the same time :) ] > > What would stop us in the future (and I believe its too late for Helios) to > switch to a pattern were all Milestones and RCs are seperate as in > http://download.eclipse.org/releases/helios/M7 > http://download.eclipse.org/releases/helios/RC1 and so on ? > This is the type of structure we currently have. One question being raised here is what should the "top level" repo point to? Currently, http://download.eclipse.org/releases/helios/ points to both http://download.eclipse.org/releases/helios/M7, and http://download.eclipse.org/releases/helios/RC1 as a composite of both. (Though they are not named M7, RC1, they have "timestamps" for directory names). I think what is being said ... and it goes beyond 'helios' repository ... is that perfectly valid repositories are not (guaranteed) to be valid in their composite -- at least valid in the sense of users being able to select and install everything. I think the way categories currently work makes this more apparent, easier to hit, but even if there were no categories, users could still hit the problem if they happened to select incompatible features. So, we could say the top level URL, http://download.eclipse.org/releases/helios/ points to only "most recent" repository, but I don't think this accomplishes original goal ... which was, that once something is installable from the repo, it should always be installable from the repo. For example, say some product or even example in a book depends on some specific feature from http://download.eclipse.org/releases/helios/ when Helios is first released (SR0), then that same product or example should still be installable from http://download.eclipse.org/releases/helios/ even after SR1 comes out, even if that specific feature is no longer in SR1 and is only in SR0. At least, that's my understanding of (one) goal. I'm not sure we can accomplish both that goal, and also that everything should be selectable and installable together. But happy to hear suggestions. And I am glad this is coming to light now, since seems to me to be a general limitation about composite repositories (right?). [But, yes, I think the scenario of selecting and installing everything may never be perfectly achievable in any large, complex repository. Perhaps a long term feature might be to allow users to "constrain" the selection, by selecting one or a few things, and then click a button that says "also select other compatible features" (or similar) ... but, again, not sure how important this is in real life].
Maybe it would help for a start if we have two repo entries in the default installation of a Eclipse IDE. One reads "Helios repo including alle milestones" and the other "Helios latest milestone". Not perfect but it makes all the transparent (aka hidden) things more obvious. For instance I am also in the overall "releng team" as David puts it and I didnt know about all the hidden composite structure. (my fault sure, but thats not the point)..... Maybe it helps for a start to make the choice more obvious.
(In reply to comment #27) > One reads "Helios repo including alle milestones" and the other "Helios latest > milestone". Not perfect but it makes all the transparent (aka hidden) things > more obvious. Just to be clear, there won't be any milestone content in the repository after we ship the release. We have that state pre-release because there is some overlap between the RC's, and also to help identify potential problems with having multiple releases in a single repository.
I understood that, but my suggestion is for the 6 month before the release where we have multiple milesstones and release candidates. I said previously that this will probably be too late for Helios but we can still learn for future can we ?
I just want to echo what John has been saying. AFAICT we are talking about a point in time issue where the current Helios repo has various milestones etc. The *released* repo will not. Helios SR1 and SR2 should absolutely NOT remove anything both in terms of no longer making a feature available or in terms of removing old versions. Removing some function/feature in a maintenance release would be like a breaking API change. Removing an old version breaks various workflows (we went through that last year and it was not good). So yes, we should not remove anything from Helios. But we have not shipped Helios yet. There is an argument that during the development cycle there should be a "pure" Helios repo that has only the "latest" in it. Sure, that would make sense since it is most close to what our ultimate end users will see. That is however unrelated to removing features from release repos (which should never be done IMHO).
(In reply to comment #26) > So, we could say the top level URL, > http://download.eclipse.org/releases/helios/ > points to only "most recent" repository, but I don't think this accomplishes > original goal ... which was, that once something is installable from the repo, > it should always be installable from the repo. One could argue that this bugzilla is good proof that this doesn't work very well when new content is added. Jeff's claim that all features must be made available in new versions doesn't help in the long run because even we enforce that, we don't have any consistency checks in place that will ensure that all prior versions of a feature is installable once a new version of that feature is added. In fact, I think the only certain way to ensure that you get the exact same install, is to *not* use the composite. The reason for that is that most features today use version ranges and not fixed versions. In short, using a composite is an almost foolproof way to ensure that you no longer can install something that you once could install. At least not in the same shape as it used to be. The feature can be found, and perhaps it can be installed, but its very very likely that it's not the same thing. So, when you say once available, always available, perhaps that should be revised to, once available, always available in some version. If we do that, then there's still no real problem having the root point to the latest release and not to the composite as it is today.
(In reply to comment #17) > (In reply to comment #16) > > I tried starting with RC1, and saw only one "conflicting dependencies" error > > (pasted below) related to GMF. > > Beware, as you can see in Comment #3 I also saw only "one" "conflicting > dependencies" error, but when I tried to "fix" it another showed up, ... Btw. is the fact that now p2 only shows one conflict per try a new feature or a bug? I found it very annoying that new conflicts kept appearing once I fixed the one shown (as you can see in Comment #3)
(In reply to comment #31) > So, when you say once available, always available, perhaps that should be > revised to, once available, always available in some version. If we do that, > then there's still no real problem having the root point to the latest release > and not to the composite as it is today. Personally I disagree with "some version". We saw what happened in Galileo when older versions got removed. In the end what was needed was a stable repo URL that would continue to hold the versions it once held. Obviously we need to keep to a minimum the number of URLs users need to know. More than one is a lot it turns out.
(In reply to comment #33) > ... More than one is a lot it turns out. I agree. The end user should not be confronted with all the complexity. That's why I'm thinking that perhaps p2 could hide this somehow? I.e. present the user with the latest release only and only consult the bigger composite when it absolutely has to. That would ensure that what's current is coherent. Compare with source in a SCM. You see HEAD. You don't want the other stuff unless you have some special requirement. When you do, you use a tag or a branch. For our end users, those occasions will be very rare. Add the added cost of dealing with meta-data that is twice, or three times as big as it needs to be to cover the common case.
Changing title to the more general issue. It appears the fix to bug 371302 worked and mostly solved this issue? The exception is the "category" is still not right. The Linux Tools category will (still) show both the SR1 and SR2 features and users do not know which to pick. I'm commenting here since this just reminds me of the discussion about having only one categorization IU for a release train, so it could be changed from release to release. This essentially means that if someone did want to "get an old feature" (that had been removed) they could not get it from the "category view", they'd just have to know name/id and which version to pick. But, despite that usability issue, the main scenarios of being able to roll back or "reproduce" an install would still work fine even if category definitions changed (as far as I know).
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Removing "stale bug" from white. board. Even though no comments, it is still an issue, as far as I know ... but, admit it needs some review, especially given p2's added ability to change a users request and offer some alternatives.
This issue has been migrated to https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/131.
