Community
Participate
Working Groups
Build Identifier: When the user installs an IU with no version specified (or using 0.0.0) p2 translates it into a range [X, X] as X is the highest version available in the known repositories. This may lead to unexpected installation failures if the highest available version of an IU is not resolvable for some reason. Version not specified or 0.0.0 is usually interpreted as whatever version that is available (belongs to [0, infinity]) by OSGi spec. This is easily reproducible when installation is done via p2 director app but it seems that p2 expects root requirements to be concrete wrt version rather than a version range. Could p2 treat v0.0.0 as the highest resolvable version that is available in the known repositories? Reproducible: Always Steps to Reproduce: test case attached
Created attachment 204547 [details] ExplanationTest adapted The new test code is directly copied from (and logically belongs to) DirectorApplicationTest but I added it to ExplanationTest since this test is not included in the test setup and won't cause unexpected test failures.
I add Tobias in Cc since this bug is related to bugs 352081 and 352560 (in see also) and it would be good if these are processed together in order to gather a full list of requirements that may exist.
"0.0.0" is in fact quite confusing, because it is used both as version and as version range. The version "0.0.0" is interpreted in the way that you want it: It means take exactly the latest, available version. This occurs for example if you tell the director to install an IU, and you don't specify the version. The version range "0.0.0" means the open range, allowing any version. If there is an open range dependency, e.g. a reference from a feature to a bundle, there is no guarantee that the latest available version is chosen, but this is subject to the weight function of the planner, which generally prefers later versions. (Bug 352560 asks why the latest version isn't chosen in one particular case). It seems, that you would like to have a new "greedily latest" version range dependency type, which would have the semantics that the planner will only match it to the latest available version and not try other versions even if this means that the install fails. I even see a use case for this for normal p2 installation scenario in Eclipse: I can greedily select the latest versions of a set of features by selecting them manually in the p2 UI, but I currently cannot get the same result through a (single) aggregation feature. The blocker that I see is that a valid p2 installation may become invalid if content is added to a referenced p2 repository. I don't believe that any normal user would understand this situation. To work around this problem, you could change the "greedily latest" semantics to not cover what is already installed, but only apply for new installations - but then things get that complicated that I'm not sure of the implications. It seems that the only solution is to implement your desired behaviour outside p2: instead of using a feature with open version range dependencies for installing multiple latest versions, either a) harden dependencies when creating the feature IU, or in case the versions are not known ahead of time, b) just store a list of IDs, look up the versions yourself, and tell p2 to install exact versions.
(In reply to comment #2) > ... this bug is related to bugs 352081 and 352560 ... Bug 352081 is a result of an "0.0.0" confusion - Tycho meant to get the latest version but used an open version range - but IMHO this just needs to be fixed in Tycho.
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.
