lib/bb/runqueue: avoid marking runtime dependencies as covered

The code which populates setscene_covered list was adding a task to the covered list if all of the tasks that depend upon it were also covered; however, this means that tasks that would have installed "runtime" dependencies were being marked as covered also, e.g. gmp-native and mpfr-native are needed by gcc-cross at runtime since they are shared libraries that gcc links to, but their do_populate_sysroot tasks were being marked as covered, resulting in failures later on if gcc-cross was available from sstate but mpfr-native and gmp-native weren't.

Since we currently have no real way to handle runtime dependencies for native packages, add a workaround which avoids marking tasks as covered if one or more of their revdeps are from a different recipe.

Fixes [YOCTO #1536].

---
 lib/bb/runqueue.py |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

index 7a39d89..a725388 100644
@@ -1208,8 +1208,13 @@ class RunQueueExecuteTasks(RunQueueExecute):
                 if task in self.rq.scenequeue_covered:
                     continue
                 if len(self.rqdata.runq_revdeps[task]) > 0 and self.rqdata.runq_revdeps[task].issubset(self.rq.scenequeue_covered):
-                    self.rq.scenequeue_covered.add(task)
                     found = True
+                    for revdep in self.rqdata.runq_revdeps[task]:
+                        if self.rqdata.runq_fnid[task] != self.rqdata.runq_fnid[revdep]:
+                            found = False
+                            break
+                    if found:
+                        self.rq.scenequeue_covered.add(task)
 
         # Detect when the real task needs to be run anyway by looking to see
         # if any of its dependencies within the same package are scheduled

1.7.5.4

Applied to master, thanks.

I have some concerns about this change in that it will cause more "work" in some cases even where it isn't needed. I'd rather that than the current situation where we don't install enough of the sstate packages though.

We're going to have to revisit this at some point but it makes sense to apply this right now.

Cheers,

Richard