| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the addition of DepPriorityNormalRange and
DepPrioritySatisfiedRange in commit
bd369956b2a2fbc019a655a372628998499156c0, which solves most cases of
bug 199856, the Depriority.rebuild attribute doesn't appear to make any
difference. The edges that this attribute differentiates are already
naturally differentiated by the fact that the child node of a satisfied
buildtime dependency that's not being rebuilt will naturally be
identified as a leaf node earlier and removed from the graph, thereby
eliminating the edge before there's an opportunity to compare it with
a higher priority rebuild edge. The addition of the "optional"
attribute (in commit 15476805a156acd11fdaaa19212691e8ee09b309) also
plays a role here, since it converts some satisfied buildtime edges to
optional edges, thereby reducing their priority.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rebuild when build-time/run-time deps are upgraded.
If pkgA has been updated, and pkgB depends on pkgA at both
build-time and run-time, pkgB needs to be rebuilt. This
feature ensures that all packages are consistent when
dependencies that are used at both runtime and build time
are changed.
This feature only rebuilds packages one layer deep. That
means that if you upgrade libcros, for example, packages
that depend directly on libcros will be rebuilt and
reinstalled, but indirect dependencies will not be rebuilt.
BUG=chromium-os:14296
TEST=Test whether packages rebuilding a bunch of packages.
Change-Id: Idbc0532b4b1de28fd9e5a0abe3b7dbe1a3abd2c8
Review URL: http://codereview.chromium.org/6905107
|
| | |
|
| |
|
|
| |
svn path=/main/trunk/; revision=13690
|
|
|
Sebastian Mingramm (few) <s.mingramm@gmx.de> for this patch.
svn path=/main/trunk/; revision=13663
|
