Diff for "Soyuz/Specs/PackagesetsAndDistroseries"

Not logged in - Log In / Register
Differences between revisions 2 and 3
⇤ ← Revision 2 as of 2009-10-13 11:59:40 →
Size: 2380
Editor: al-maisan
Comment:
← Revision 3 as of 2009-10-13 12:23:12 → ⇥
Size: 2390
Editor: al-maisan
Comment:
Deletions are marked like this. Additions are marked like this.
Line 15: Line 15:
There is also a somewhat vague realisation that package sets are an "interesting" datum 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. There is also a (somewhat vague) realisation that package sets are an "interesting" type of datum 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.

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 an "interesting" type of datum 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.

Soyuz/Specs/PackagesetsAndDistroseries (last edited 2009-10-13 14:21:03 by al-maisan)