| Age | Commit message (Collapse) | Author |
|---|
|
A recipes can generate several rpms such as a.rpm, a-dev.rpm, a-dbg.rpm,
when update one of them in the repo, we'd better update all of them,
otherwise, there might be a-dev.r0.1.rpm and a-dbg.r0.3.rpm in the repo,
which looks strange.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
* fix for python3
iteritems() -> items()
* Return immediately for native and cross.
* Remove the usage of __BBDELTASKS, there is no such var in bitbake.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
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.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
Robert Yang
Paul Eggleton