[OE-core] What does "QA Issue: ... rdepends on .. but its not a build dependency?" mean

Mike Looijmans mike.looijmans at topic.nl
Sun Aug 3 17:35:11 UTC 2014


On 08/03/2014 06:07 PM, Richard Purdie wrote:
> On Sun, 2014-08-03 at 15:25 +0200, Mike Looijmans wrote:
>> I'm getting lots of warnings like this:
>>
>> """
>> WARNING: QA Issue: enigma2-plugin-systemplugins-wirelesslan rdepends on
>> wireless-tools but its not a build dependency? [build-deps]
>> """
>>
>> What does it actually mean? What does it want me to provide here?
>>
>> The message in itself is correct. The package only has a runtime
>> dependency. It does not require the wireless-tools package to be built
>> or otherwise present on the build system. But what is the QA issue here
>> and how do I get rid of the message?
>
> The issue is that if you built an image that just depends on whichever
> recipe builds enigma2-plugin-systemplugins-wirelesslan and you try and
> install that into an image without something else depending on
> wireless-tools, the build will fail.
>
> Sometimes (like this case) these are genuine runtime dependencies and
> you therefore just need to make the dependency visible to bitbake.
> Sometimes these can be floating autodetected dependencies which should
> wither have been in DEPENDS or turned off with PACKAGECONFIG.
>
> In this case I'm going to guess that the plugin is part of a
> PACKAGES_DYNAMIC and hence bitbake can't see the dependency until its
> too late (once the package is built).
>
> Adding the package name to PACKAGES would probably allow bitbake to
> "see" it and avoid the problem.
>
> Yes, bitbake could in theory go though all the RDEPENDS/RRECOMMENDS_*
> variables and try and guess which ones to look at however it would kill
> parsing time :/.

And in this particular case, even that would not help - the dependencies 
are being calculated after the "install" task has completed. There's 
code in the recipe that parses the output of the plugins and then sets a 
bunch of RDEPENDS and similar values for the package.

I think the easy workaround here would be to just add it to the DEPENDS 
list - this particular recipe has been ported along from ancient OE, and 
it already has to wait for tons of other things, because it builds about 
a hundres useless plugins. The newer plugin recipes tend to have a 
recipe each, so they don't cause this kind of problems.


-- 
Mike Looijmans



More information about the Openembedded-core mailing list