Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Equinox/p2/Proposals/Categories API
< Equinox | p2
Revision as of 06:39, 22 September 2009 by Henrik.lindberg.puppet.com (Talk | contribs)
W.I.P
After having used p2's provisional API for building p2 related tools, we have found several issues regarding the category management in 3.5. This page is an attempt to describe the issue, propose requirements on a solution, and then a suggested implementation.
Contents
What are the problems
When older update sites are transformed to p2, a new category IU is created on each visit. Each newly created IU has a unique version based on a timestamp.
This leads to:
- In order to understand if categorization has changed, the current categorization has to be compared.
- Since it is not possible to know if the category is originally from a old update site, comparisons are always needed
A Category is an Installable Unit, but is not installed
This leads to:
- Exceptional logic whenever a category is found in a result.
- All usage requires the exceptional handling, but the only use case where categories have a role is when presenting a categorized view of what to install to the user.
Missing Features
The categorization in 3.5 only solves the need to present things to install in a human friendly way.
- All users of a repository are presented with the same view irrespective of if they are developers or users of a published software.
- As a consequence, it is not possible to organize "technical" things for technical people
- There is no structure to categories (i.e. no subcategories) - which in very large repositories becomes a problem
Requirements on a Solution
- it is unlikely that it is possible to force all older update site owners to change to p2, or have them name/version categories.
- Blocking older update sites in p2 is not a solution.