Diff for "Soyuz/ArchAllDomination"

Not logged in - Log In / Register

Differences between revisions 1 and 2
Revision 1 as of 2011-10-03 14:06:41
Size: 1373
Comment:
Revision 2 as of 2011-10-03 14:13:20
Size: 1400
Comment:
Deletions are marked like this. Additions are marked like this.
Line 15: Line 15:
  *Pros*::
    Can make better use of the build farm by removing nominatedarchindep and building on all architectures.
  *Cons*::
    Difficult and time-consuming to implement
  *Pros*:
    - Can make better use of the build farm by removing nominatedarchindep and building on all architectures.
  *Cons*:
    - Difficult and time-consuming to implement
Line 25: Line 25:
  *Pros*::
    Easy-ish to implement; requires thought about performance degradation
  *Cons*::
    Another special case; doesn't head in the "right" direction as above; potentially leaves some binaries hanging around longer than necessary
  *Pros*:
    - Easy-ish to implement;
    - requires thought about performance degradation
  *Cons*:
    - Another special case;
    - doesn't head in the "right" direction as above;
    - potentially leaves some binaries hanging around longer than necessary
Line 33: Line 36:
  *Pros*::
    Overcomes the limitation of the previous solution where binaries linger longer than necessary
  *Cons*::
    Considerably harder to implement
  *Pros*:
    - Overcomes the limitation of the previous solution where binaries linger longer than necessary
  *Cons*:
    - Considerably harder to implement
Rendering of reStructured text is not possible, please install Docutils.

================
Fixing bug 34086
================

There's a few options:

**A new architecture type**
  Instead of borrowing "i386" as an arch-all architecture, we could have a
  "archall" architecture (albeit special-cased) thus allowing us to give
  arch:all packages their own BPRs and only garbage-collect them when the
  source is superseded

  *Pros*:
    - Can make better use of the build farm by removing nominatedarchindep and building on all architectures.
  *Cons*:
    - Difficult and time-consuming to implement

**Dominate in binary groupings**
  Only dominate all a source's binaries in one DAS all at once, or not at all.
  Effectively, this is preventing the arch:all from being dominated too early
  when other binaries in the same DAS cannot be dominated yet.

  *Pros*:
    - Easy-ish to implement;
    - requires thought about performance degradation
  *Cons*:
    - Another special case;
    - doesn't head in the "right" direction as above;
    - potentially leaves some binaries hanging around longer than necessary

**Track dependencies in the packages**
  Reference count dependencies on arch:all binaries and only dominate when the reference count is zero.

  *Pros*:
    - Overcomes the limitation of the previous solution where binaries linger longer than necessary
  *Cons*:
    - Considerably harder to implement 

Soyuz/ArchAllDomination (last edited 2011-10-04 10:18:17 by julian-edwards)