Community
Participate
Working Groups
(There might be a bug on this topic already ... but couldn't find it, and wanted to make sure the issue is better understood for Indigo, so am opening this one). Last year, shortly before release, an issue came where projects were specifying "loose" requirements for feature "includes". See http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg04201.html I can't say I completely understand all the issues, but the topic came up again as a side discussion in another bug (See 324419#c6) ... and it implied a very common case (I'd think) that could result in similar "bad install state" issue. The common case is where a "required package" is greedily installed. I sort of thought it was recommended to minimize feature specifications, but this issue implies that if a bundle _only_ requires a package, that a feature might not be able to be reliably reverted (or, I'd assume, a build be perfectly reproducible). So two actions immediately come to mind, for Indigo. 1) we should improve the "how to specify feature requirements" documentation. There is some of this documented in http://wiki.eclipse.org/index.php/Version_Numbering#To_require_features_or_to_require_bundles but not sure it covers this "require package" case adequately. 2) we should figure out how to test if an install (or all the features in a repository?) are "revertible". I've no idea how to do that ... but sounds important. Of course, there's also the possible action of how to actually _support_ having these types of loosely required includes ... but, at the moment, I don't understand the use-case very well. I know it's related to allowing "easier", more flexible updates ... but I think it will take some education and discussion to understand better ... and once understood, other teams (p2?) would have to decide if could be supported, while at the same time supporting clean reverts and reproducible builds.
I'm going to assign this to Thomas, since he was heavily involved in the previous issue and discussion at the end of Helios ... if not the instigator :) But I'm not implying all actions are his to solve. I just didn't want too much spam sent out ... so add yourself to CC if you want to follow this bug. Advice welcome. (And, you can assign back to me, Thomas, if you don't plan to do anything in this area).
I think this should really be viewed as an enhancement in p2. There is no authoring format today for someone to define loose requirements (including with a range). We have discussed in the past being able to specify both a precise version and a range on a feature inclusion, and make it an option at install time whether you install strictly using precise versions (notion of "line-up"), or a range. I can't find an existing bug with this discussion but maybe Pascal knows of one.
(In reply to comment #2) > I think this should really be viewed as an enhancement in p2. There is no > authoring format today for someone to define loose requirements (including with > a range). ... I think it is fine to view the _support_ of loose requirements as a p2 enhancement, and if you find that bug number, it'd be great to reference here ... but ... a) I think buckminster has an "authoring format" ... at least of a sorts (the sorts that doesn't play well with these other requirements of reproducible builds and revert-ability, so should not be used) b) _this_ bugzilla is meant mostly as a way to document how to avoid accidentally introducing "loose" requirements (or, more precisely, to document how to avoid breaking revert-ability). For example, if a plugin "requires" a package import, then should they (someone, somewhere) make sure a feature requires/includes a suitable version of that plugin. Can some revert "break" such a plugin accidentally? Maybe not. Maybe the supposition in bug 324419#c6 was/is incorrect? c) also this issue is about how to test. In http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg04201.html Jeff mentions it'd be a nice sanity check to test repos, but I've no idea how to do that ... so hoping someone will attach a nice working patch :) Is there a way to "test for revert-ability"? Or maybe we don't need to after all? There's plenty of other things we should test ... I'm not saying this is urgent ... just didn't want it to get lost.
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.
Too much bitrot on this one.
