On Tue, 6 Aug 2019 at 16:16, Richard Purdie < richard.pur...@linuxfoundation.org> wrote:
> I partly agree with this. There is: > > insane.bbclass:do_package_qa[rdeptask] = "do_packagedata" > > which does help the situation by forcing package_qa after all the > runtime dependencies. > > I suspect the real problem is that it can also see RDEPENDS for things > it doesn't rdepend upon... > > You might want package_prepare_pkgdata() from package_pkgdata called > for package_qa's context on a separate directory, then to use that as > the pkgdata to resolve against? > > Note that package_prepare_pkgdata() called for do_package is different > than package_prepare_pkgdata() called for do_package_qa as the tasks > have different dependencies... > I am actually inclined to remove the recursive resolver in insane.bbclass. It gives a QA pass to a situation when there is a bash script in A, and the bash runtime dependency is satisfied indirectly through a chain of arbitrary length: A -> bash-completion -> bash. It becomes hard to reason where the dependencies come from; I think any runtime dependencies should be explicitly listed. We may need to fix up a few recipes, but the outcome is a better definition of runtime dependencies. I have confirmed that for stress-ng removing the recursive resolver and adding an explicit RDEPENDS on bash solves the issue (stress-ng package_qa does not start until bash packaging completes, unlike previously). Alex
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
