• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

Associating package sets and distro series

In the previous analysis of the problem two possibilites to associate package sets and distro series were identified. The conceptually more attractive one (Copy on write) unfortunately comes at a considerable higher cost and risk.

Currently, there are three types of data that relate to package sets: the

1. package set inclusion hierarchy (a DAG that captures how package sets hang together)

2. many-to-many inclusion relationship between package sets and (source) packages (captured by the packagesetsources table)

3. package set based archive permissions (stored in the archivepermission table)

There is a requirement to tether the latter two to a distro series for the purposes of distro development.

There is also a (somewhat vague) realisation that package sets are "interesting" data that could potentially be utilised more widely across Launchpad coupled with the concern that their utility would be diminished if they were to have a distro series "life span" i.e. if we introduced a new incarnation of a package set (with a new database key) whenever the development of a new distro series begins.

On the other hand, the only package set use cases we have are the ones put forward by the distro development team.

Is it worthwhile pursuing a compromise that

• avoids
  • limiting the life cycle of package sets to a single distro series

  • the complexity/risk/cost of the copy on write approach

• gives the distro development team a clean slate for every distro series when it comes to
  • package set and (source) package inclusion relationships
  • archive permissions

If we wanted it we could e.g. add a DistroSeries foreign key to the packagesetsources and the archivepermission tables (PATCH) as well as engage in a bit of data cloning in the database for each new distro series (when a new distro series (ds-N+1) is created, all packagesetsources/archivepermission rows for ds-N are copied and immediately updated to refer to (ds-N+1)).

A shortcoming of this approach is that the package set hierarchy is "global" i.e. cannot be changed for each distro series anew.

BTW, here's another schema modelling variant, more along the lines of the "shared nothing" approach. The assumption is that the original package set and its clones (introduced in the process of initialising new distro series as time goes on) form a package set "group".

The forthcoming Launchpad work-flows would then rather be referring to a packagesetgroup as opposed to specific package sets (that are tied to their respective distro series).