aboutsummaryrefslogtreecommitdiffstats
path: root/meta/classes/packagefeed-stability.bbclass
AgeCommit message (Collapse)Author
2016-01-21packagefeed-stability: copy all packages as soon as one differsjoshuagl/packagefeed-stabilityJoshua Lock
Simplify the logic somewhat by copying all packages in a manifest as soon as one is found which fails the pkg-diff comparison. Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
2016-01-15packagefeed-stability: work around a couple of issuesJoshua Lock
Possibly temporary workarounds to facilitate an initial build: * Prevent do_package_compare being run for native packages (this is a hammer to prevent trying to run build-compare on the build-compare-native package) * Prevent do_package_compare being run for recipes where PACKAGES is empty (this was to prevent trying to run do_package_compare on gcc-source, which has no packages) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
2016-01-15packagefeed-stability: ensure the -prediff dir is createdJoshua Lock
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
2016-01-14WIP: classes/packagefeed-stability: add class to help reduce package feed churnPaul Eggleton
When a dependency causes a recipe to effectively be rebuilt, its output may in fact not change; but new packages (with an increased PR value, if using the PR server) will be generated nonetheless. There's no practical way for us to predict whether or not this is going to be the case based solely on the inputs, but we can compare the package output and see if that is materially different and based upon that decide to replace the old package with the new one. This class effectively intercepts packages as they are written out by do_package_write_*, causing them to be written into a different directory where we can compare them to whatever older packages might be in the "real" package feed directory, and avoid copying the new package to the feed if it has not materially changed. We use build-compare to do the package comparison. (NOTE: this is still a work in progress and there are no doubt unresolved issues.) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>