⇤ ← Revision 1 as of 2011-10-03 14:06:41
1373
Comment:
|
1400
|
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 |
================ 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