What does "QA Issue: ... rdepends on .. but its not a build dependency?" mean

What does "QA Issue: ... rdepends on .. but its not a build dependency?" mean

[Mike Looijmans]

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?

Apart from that, there's a spelling error in there (its -> it's) because 
it's "it's" when it's "it is" and it's "its" when it's its property.

-- 
Mike Looijmans

Re: What does "QA Issue: ... rdepends on .. but its not a build dependency?" mean

[Alex J Lennon]

On 03/08/2014 14:25, 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?
>

Surely if package B has a non-optional runtime dependency on package A
then package A must be built and present on the target ?

> Apart from that, there's a spelling error in there (its -> it's)
> because it's "it's" when it's "it is" and it's "its" when it's its
> property.
>

It is a spelling error in a superficial sense perhaps, but at a deeper
level I suspect it is more accurately characterised as a grammatical error.

Perhaps somebody was having trouble with string terminations and decided
to avoid trouble?

Cheers,

Alex

Re: What does "QA Issue: ... rdepends on .. but its not a build dependency?" mean

[Mike Looijmans]

On 08/03/2014 03:51 PM, Alex J Lennon wrote:
>
> On 03/08/2014 14:25, 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?
>>
>
> Surely if package B has a non-optional runtime dependency on package A
> then package A must be built and present on the target ?

Yes, I agree.

But that does not help me understand the message. What does it want me 
to do here?

The message seems to suggest that package A must be in the DEPENDS list 
for package B, which is definitely not the case here. Package B contains 
some scripts and config files, and has an architecture of "all" and can 
be built even way before the compiler and C libraries are present on the 
build host. Package A however needs lots of other things, and will 
likely start building much later than that.


-- 
Mike Looijmans

Re: What does "QA Issue: ... rdepends on .. but its not a build dependency?" mean

[Richard Purdie]

On Sun, 2014-08-03 at 14:51 +0100, Alex J Lennon wrote:
> On 03/08/2014 14:25, 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?
> >
> 
> Surely if package B has a non-optional runtime dependency on package A
> then package A must be built and present on the target ?

Its the "built" part that is the issue, bitbake can't see the
dependency, hence the warning.

> > Apart from that, there's a spelling error in there (its -> it's)
> > because it's "it's" when it's "it is" and it's "its" when it's its
> > property.
> >
> 
> It is a spelling error in a superficial sense perhaps, but at a deeper
> level I suspect it is more accurately characterised as a grammatical error.
> 
> Perhaps somebody was having trouble with string terminations and decided
> to avoid trouble?

Somebody was concentrating on the correctness of the code generating the
warning rather than the grammar. The latter is easily fixed, patches
welcome.

Cheers,

Richard

Re: What does "QA Issue: ... rdepends on .. but its not a build dependency?" mean

[Alex J Lennon]

On 03/08/2014 17:16, Richard Purdie wrote:
> On Sun, 2014-08-03 at 14:51 +0100, Alex J Lennon wrote:
>> On 03/08/2014 14:25, 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?
>>>
>> Surely if package B has a non-optional runtime dependency on package A
>> then package A must be built and present on the target ?
> Its the "built" part that is the issue, bitbake can't see the
> dependency, hence the warning.
>
>>> Apart from that, there's a spelling error in there (its -> it's)
>>> because it's "it's" when it's "it is" and it's "its" when it's its
>>> property.
>>>
>> It is a spelling error in a superficial sense perhaps, but at a deeper
>> level I suspect it is more accurately characterised as a grammatical error.
>>
>> Perhaps somebody was having trouble with string terminations and decided
>> to avoid trouble?
> Somebody was concentrating on the correctness of the code generating the
> warning rather than the grammar. The latter is easily fixed, patches
> welcome.
>

I stand corrected :)

Cheers, Alex

Re: What does "QA Issue: ... rdepends on .. but its not a build dependency?" mean

[Richard Purdie]

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 :/.

Cheers,

Richard

Re: What does "QA Issue: ... rdepends on .. but its not a build dependency?" mean

[Mike Looijmans]

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

Re: What does "QA Issue: ... rdepends on .. but its not a build dependency?" mean

[Mike Looijmans]

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

Re: 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@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/