<div dir="ltr"><div dir="ltr">On Tue, 6 Aug 2019 at 15:22, Alexander Kanavin <<a href="mailto:alex.kanavin@gmail.com">alex.kanavin@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I think the issue might be actually in the QA check where it looks
beyond the recipe's immediate RDEPENDS (and then fails or not depending
on whether those indirect dependencies have been packaged). I need to better understand what happens there so will add some printouts first. The problem does happen with latest master.<br></div></blockquote><div><br></div><div>I can confirm that this bit in insane.bbclass is non-deterministic:</div><div><br></div><div> # Find all the rdepends on the dependency chain<br> while next:<br> new = []<br> for rdep in next:<br> rdep_data = oe.packagedata.read_subpkgdata(rdep, d)<br> sub_rdeps = rdep_data.get("RDEPENDS_" + rdep)<br> if not sub_rdeps:<br> continue<br> for sub_rdep in bb.utils.explode_deps(sub_rdeps):<br> if sub_rdep in done:<br> continue<br> if oe.packagedata.has_subpkgdata(sub_rdep, d):<br> # It's a new rdep<br> done.append(sub_rdep)<br> new.append(sub_rdep)<br> next = new</div><div><br></div><div>It only fully expands the dependencies if all of them have been already packaged. As there is no mechanism to ensure that package_qa runs after packaging all of the recursive RDEPENDS, this is causing a race between packaging them, and running the package qa check.</div><div><br></div><div>I think the right way to address this is to actually drop the recursive RDEPENDS resolution, and only consider the immediate runtime dependencies. Alternatively, we may introduce additional task dependencies to fix the race. Thoughts?</div><div><br></div><div>Alex<br></div></div></div>