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

[Mike Looijmans]

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

Interestingly, the result of fixing this warning - now that I grasp its 
meaning - is quite good. It turned out that three of these plugins depended on 
packages that could not be built. The others that triggered this warning now 
have their RDEPENDS listed in the main recipe, and the build nicely includes 
the depended upon packages, solving both the warning and the potential problem 
it signals.

I think the warning message should be expanded with a little explanation 
though. It clearly states what the situation is, it just doesn't say anything 
about what's wrong with that situation. Although googling on it will now 
likely lead to this thread and explain it...

Mike.


Met vriendelijke groet / kind regards,

Mike Looijmans

TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijmans at topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Topic zoekt FPGA experts
http://topic.nl/vacatures/word-jij-onze-nieuwe-fpga-expert/