Bugzilla – Full Text Bug Listing
| Summary: | [agent] Confusing tags in "Update Details" dialog | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Pawel Pogorzelski <pawel.pogorzelski1> | ||||
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> | ||||
| Status: | RESOLVED DUPLICATE | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | aniefer, kim.moir, pascal | ||||
| Version: | 3.6 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
I remember that I talked to Kim about it and she gave me a satisfactory explanation. The feature date is changed only when the feature project is tagged. This is not required when required capabilities (nested features or plug-ins) are changed. I hope that Kim will put it right, if I am wrong or not precise :-) The parents here are features, in addition to being grouping mechanism for the children they also deliver content of their own. The date generally reflects the last time the feature itself changed, which occurs less often than when the children change. The extra version stuff after the date is an ecoding of the the base-64 sum of the versions of all the children, which should increase any time a child increases its version. v20090727-7Z7-FGBFE-z0VXhX4016JM73 --------- ------------------------ date children encoding There may be another bug around somewhere about these being not-nice to look at. That's interesting. So we are saying that a change in requirements is not a change in the IU? I thought at one time we said that a particular version of an IU should be the same in any repo. It sounds now as if we are saying that a particular version of a group IU may stay the same even if it's required capabilities change? (I think we can close this bug but it's worth clarifying in this bug so we can refer to it later) (In reply to comment #3) > That's interesting. > So we are saying that a change in requirements is not a change in the IU? > I thought at one time we said that a particular version of an IU should be the > same in any repo. It sounds now as if we are saying that a particular version > of a group IU may stay the same even if it's required capabilities change? > > (I think we can close this bug but it's worth clarifying in this bug so we can > refer to it later) > The version of the IU is changing due to the extra version suffix increasing whenever one of the required versions changes. These suffixes are automatically generated by pde.build. So the date portion remains the same, but the entire version does change. (In reply to comment #2) > The extra version stuff after the date is an ecoding of the the base-64 sum of > the versions of all the children, which should increase any time a child > increases its version. > > v20090727-7Z7-FGBFE-z0VXhX4016JM73 > --------- ------------------------ > date children encoding If it's a hash then I suspect it doesn't increment only changes in an unpredictable way. Right? Also, I thought features are a legacy mechanism. To what extend p2 agent use features? Does p2 agent maps IU to features? I'm an end user in this matter and without the knowledge about features and how they are build it's hard to tell what the date/tag next to the IU means. As I suspect novice users are also confused with the present state. See the tag next to Eclipse Project SDK feature in the attached file. Most of users would think such an update would actually downgrade the installation. However I don't know if this is a shortcoming of convention used by Eclipse build environment or a problem that can be addressed at p2 level. (In reply to comment #5) > (In reply to comment #2) > > The extra version stuff after the date is an ecoding of the the base-64 sum of > > the versions of all the children, which should increase any time a child > > increases its version. > > > > v20090727-7Z7-FGBFE-z0VXhX4016JM73 > > --------- ------------------------ > > date children encoding > > If it's a hash then I suspect it doesn't increment only changes in an > unpredictable way. Right? > Its not a hash. It is predictable and will increment if any children are incremented. (With the exception that by default build truncates the suffix at 28 characters with the result that small changes in the least significant digits may be lost, see bug 208143 and bug 175714). Features are still the mechanism used at build time. A feature "org.foo" will be mapped to a group IU "org.foo.feature.group" and a IU for the feature jar "org.foo.feature.jar", as well as possibly root file IUs per platform eg: "org.foo_root.win32.win32.x86". The agent itself is only dealing with IUs. I'm going to mark this as a duplicate of bug 263998 *** This bug has been marked as a duplicate of bug 263998 *** |
Created attachment 143491 [details] Update Details dialog I have Update Details dialog which is populated with data unclear to me. Given there is a hierarchical structure I would expect the date that appear next to the parent item is newer or equal to any date of it's children. This is not the case. The same happens when I click "more" for "Eclipse PDE Plug-in Developer Resources" leaf. The item requires capabilities tagged with newer dates than the item itself. See the attachment for details.