[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:48:34 UTC 2014


On 08/03/2014 07:35 PM, Mike Looijmans wrote:
> 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.

Hmm, that did NOT work. I added everything it warned about to the 
DEPENDS list, but it did not make a difference. I still got the warnings.


-- 
Mike Looijmans



More information about the Openembedded-core mailing list