This constraints set, with a "merge as late as possible" heuristic, would give one of this two schedules:
- build A | - build C - build C | - build A - merge C | - merge C - build B | - build B - merge B | - merge B - merge A | - merge A
They never break system consistency, but keep the benefits of Spider's suggestion.
This is an interesting idea, but I wonder what happens when a runtime dependency is a compile time dependency for another component. This constraint could reduce 'merge as late as possible' to 'merge as soon as possible'. E.g:
A rdep B cdep C D cdep A
Using the merge as late as possible heuristic, we get:
1 . C and A have no cdep
build(C,A)
2. B and D cdep C and A
merge(C,A)
3. B and D have no cdep
build(B,D)
4. merge remaining
merge(B,D)
Which is exactly the same result as obtained using a "merge as soon as possible" heuristic.
So, the strategy you describe only has the expected benefit for runtime dependencies on which no other component cdepends, or in cases where the cdepend on the package to be merged is only discovered at a very late time while scheduling. I think the tinderbox approach used for catalyst offers some better developer-side QA benefits (at least of importance for developers). I also think most users would expect (at least the packages they want) to be merged as soon as possible, but we could allow for users specifying such things :-)
Pieter
-- [EMAIL PROTECTED] mailing list
