On Tue, 6 Aug 2019 at 15:22, Alexander Kanavin <alex.kana...@gmail.com>
wrote:
> 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.
>
I can confirm that this bit in insane.bbclass is non-deterministic:
# Find all the rdepends on the dependency chain
while next:
new = []
for rdep in next:
rdep_data = oe.packagedata.read_subpkgdata(rdep, d)
sub_rdeps = rdep_data.get("RDEPENDS_" + rdep)
if not sub_rdeps:
continue
for sub_rdep in bb.utils.explode_deps(sub_rdeps):
if sub_rdep in done:
continue
if oe.packagedata.has_subpkgdata(sub_rdep, d):
# It's a new rdep
done.append(sub_rdep)
new.append(sub_rdep)
next = new
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.
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?
Alex
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
