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.
Difference between revisions of "Equinox/p2/Repository Association"
| Line 9: | Line 9: | ||
# Feature discovery sites. Each feature could optionally specify one or more update sites containing features of interest to users of that features. These repositories would be shown to the user at the beginning of the install wizard workflow | # Feature discovery sites. Each feature could optionally specify one or more update sites containing features of interest to users of that features. These repositories would be shown to the user at the beginning of the install wizard workflow | ||
# Associate sites. Each site 'S' could specify additional associate sites. Those associate sites would be used in the context of any provisioning operation against site 'S'. This is how Update Manager handled provisioning operations spanning multiple sites. | # Associate sites. Each site 'S' could specify additional associate sites. Those associate sites would be used in the context of any provisioning operation against site 'S'. This is how Update Manager handled provisioning operations spanning multiple sites. | ||
| + | # Site policy file. A policy file can be specified, which causes feature updates to be redirected to an alternate site. | ||
| + | |||
| + | The problem with 1 and 2 above is that they represent the producer's view of what site should be used when updating a feature. A consumer wishing to control the sites shown to their user, or wishing to use internal mirrors to save bandwidth, may want to override the producer's choice of update site. Policy files help with this problem by redirecting the sites specified for 1 above. They didn't offer strong control because the policy file had to be set by the end user. The had the additional problem that since the policy file was typically on a server, the product would default back to the producer's choice of sites when the policy server is unreachable. | ||
Revision as of 17:37, 12 November 2008
This page is for collecting background information, requirements, and proposed solutions for the p2 Galileo plan item on improving the repository association model. Roughly, this problem area has two facets:
- Association of repositories with installable units. How are the repositories initially seeded, and how does an administrator or bundle provider specify/control the repositories used to install/update a given IU?
- Association of repositories with each other. How do groups of repositories interact to perform provisioning operations that span multiple repositories?
Historical Information
Repository Association in Update Manager
Prior to the introduction of p2, Update Manager (UM for short), had various mechanisms for managing repository associations:
- Feature update sites. Each feature specified the update site to be used for updating that feature. If a parent feature included a child feature, the parent feature's update site would override the child's update site.
- Feature discovery sites. Each feature could optionally specify one or more update sites containing features of interest to users of that features. These repositories would be shown to the user at the beginning of the install wizard workflow
- Associate sites. Each site 'S' could specify additional associate sites. Those associate sites would be used in the context of any provisioning operation against site 'S'. This is how Update Manager handled provisioning operations spanning multiple sites.
- Site policy file. A policy file can be specified, which causes feature updates to be redirected to an alternate site.
The problem with 1 and 2 above is that they represent the producer's view of what site should be used when updating a feature. A consumer wishing to control the sites shown to their user, or wishing to use internal mirrors to save bandwidth, may want to override the producer's choice of update site. Policy files help with this problem by redirecting the sites specified for 1 above. They didn't offer strong control because the policy file had to be set by the end user. The had the additional problem that since the policy file was typically on a server, the product would default back to the producer's choice of sites when the policy server is unreachable.