update-rc.d: don't add runtime dependency if not doing online package management; only add it to ${PN} in any case.

update-rc.d: don't add runtime dependency if not doing online package management; only add it to ${PN} in any case.

[Denys Dmytriyenko]

Hi,

The commit ee690abcef0df80271729ca869f19164b1c15bbe[1] (update-rc.d: don't 
add runtime dependency if not doing online package management; only add it to 
${PN} in any case) breaks one important feature - additional runtime 
dependencies for packages, inheriting update-rc.d class.

One of the examples is udev (udev-utils is no longer a dependency):

$ dpkg-deb -I old/udev_141-r10.2_armv5te.ipk |grep Depends
 Depends: udev-utils, libc6, libvolume-id1 (>= 141)
$ dpkg-deb -I angstrom/udev_141-r10.2_armv5te.ipk |grep Depends
 Depends: udev-utils, libc6 (>= 2.6.1), libvolume-id1 (>= 141)

$ dpkg-deb -I new/udev_141-r10.2_armv5te.ipk |grep Depends
 Depends: update-rc.d, libc6, libvolume-id1 (>= 141)

The problem comes from the fact that either RDEPENDS_{PN}_append = "blah" or 
RDEPENDS_{PN} += "blah" used in the class overwrite the value set in 
inheriting recipe, instead of appending to it. The position of the inherit 
command in the recipe relative to its own RDEPENDS does not matter. And I 
don't think this issue only applies to RDEPENDS variable...

It used to "work" before, because update-rc.d.bbclass had the wrong 
RDEPENDS_append and "update-rc.d" was never added to the runtime dependencies, 
while more important udev-utils was.

I tried latest branches/bitbake-1.8 - no difference.

The short-term solution is to revert the commit in question. The correct 
solution is to find the underlying problem. Any takers?

[1] http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=ee690abcef0df80271729ca869f19164b1c15bbe

-- 
Denys

Re: update-rc.d: don't add runtime dependency if not doing online package management; only add it to ${PN} in any case.

[Phil Blundell]

On Wed, 2009-06-17 at 00:29 -0400, Denys Dmytriyenko wrote:
> The problem comes from the fact that either RDEPENDS_{PN}_append = "blah" or 
> RDEPENDS_{PN} += "blah" used in the class overwrite the value set in 
> inheriting recipe, instead of appending to it. The position of the inherit 
> command in the recipe relative to its own RDEPENDS does not matter. And I 
> don't think this issue only applies to RDEPENDS variable...

I've checked in a change to udev-141 that I think should fix this.
(Other versions didn't seem to be affected.)  Please give that a go and
see if it works for you now.

p.

Re: update-rc.d: don't add runtime dependency if not doing online package management; only add it to ${PN} in any case.

[Denys Dmytriyenko]

On Wed, Jun 17, 2009 at 08:40:50AM +0100, Phil Blundell wrote:
> On Wed, 2009-06-17 at 00:29 -0400, Denys Dmytriyenko wrote:
> > The problem comes from the fact that either RDEPENDS_{PN}_append = "blah" or 
> > RDEPENDS_{PN} += "blah" used in the class overwrite the value set in 
> > inheriting recipe, instead of appending to it. The position of the inherit 
> > command in the recipe relative to its own RDEPENDS does not matter. And I 
> > don't think this issue only applies to RDEPENDS variable...
> 
> I've checked in a change to udev-141 that I think should fix this.
> (Other versions didn't seem to be affected.)  Please give that a go and
> see if it works for you now.

Hmm, it works, thanks! I was pretty sure I tried this before I sent out my 
email...

Any ideas why RDEPENDS_{PN} in "udev" recipe works, but RDEPENDS_udev doesn't? 
It only happens with inherit update-rc.d.bbclass, which also changes 
RDEPENDS_{PN}... I have the same issue with my own recipes, which I need to 
fix similarly.

-- 
Denys

Re: update-rc.d: don't add runtime dependency if not doing online package management; only add it to ${PN} in any case.

[Phil Blundell]

On Wed, 2009-06-17 at 17:41 -0400, Denys Dmytriyenko wrote:
> Any ideas why RDEPENDS_{PN} in "udev" recipe works, but RDEPENDS_udev doesn't? 
> It only happens with inherit update-rc.d.bbclass, which also changes 
> RDEPENDS_{PN}... I have the same issue with my own recipes, which I need to 
> fix similarly.

It's a side effect of the way that overrides work in bitbake.  What
happens is that you start with:

RDEPENDS_udev = "something"
# RDEPENDS_${PN} is not set
RDEPENDS_${PN}_append = "foo"

First, bitbake processes the _append, which causes a new variable
RDEPENDS_${PN} to be created.  (It doesn't append to RDEPENDS_udev
because, at this stage, that is a different variable name.)  So now you
have:

RDEPENDS_udev = "something"
RDEPENDS_${PN} = "foo"

Finally. bitbake expands the expressions on the left-hand side.  At this
point the latter variable's name is transformed into RDEPENDS_udev and
hence it will overwrite the former one.  Which variable "wins" in this
case is a little bit unpredictable although I think that, with the
current bitbake, a variable whose name goes through more transforming
steps is likely to defeat one whose name is simpler.

The practical effect of this is that, in almost all circumstances, you
should set and refer to RDEPENDS_${PN}, RDEPENDS_${PN}-dev and so on,
rather than pre-expanding those values by hand.

p.

Re: update-rc.d: don't add runtime dependency if not doing online package management; only add it to ${PN} in any case.

[Phil Blundell]

On Fri, 2009-06-19 at 08:36 +0100, Phil Blundell wrote:
> On Wed, 2009-06-17 at 17:41 -0400, Denys Dmytriyenko wrote:
> > Any ideas why RDEPENDS_{PN} in "udev" recipe works, but RDEPENDS_udev doesn't? 
> > It only happens with inherit update-rc.d.bbclass, which also changes 
> > RDEPENDS_{PN}... I have the same issue with my own recipes, which I need to 
> > fix similarly.
> 
> It's a side effect of the way that overrides work in bitbake. 

... and Chris Larson, being the great guy that he is, has now added a
check for this issue to recipe_sanity.bbclass.  If you have sanity
checking enabled, this situation will now elicit a diagnostic along the
lines of:

NOTE: glibc-2.9: recipe_sanity: rename of variable 'RPROVIDES_${PN}-dev'
to 'RPROVIDES_glibc-dev' overwrote existing value ' libc-dev' with
'libc6-dev virtual-libc-dev'. 

which should make it easy to identify such issues in the future.  Thanks
Chris!

p.

Re: update-rc.d: don't add runtime dependency if not doing online package management; only add it to ${PN} in any case.

[Christopher Larson]

Phil Blundell wrote:
> On Fri, 2009-06-19 at 08:36 +0100, Phil Blundell wrote:
>   
>> On Wed, 2009-06-17 at 17:41 -0400, Denys Dmytriyenko wrote:
>>     
>>> Any ideas why RDEPENDS_{PN} in "udev" recipe works, but RDEPENDS_udev doesn't? 
>>> It only happens with inherit update-rc.d.bbclass, which also changes 
>>> RDEPENDS_{PN}... I have the same issue with my own recipes, which I need to 
>>> fix similarly.
>>>       
>> It's a side effect of the way that overrides work in bitbake. 
>>     
>
> ... and Chris Larson, being the great guy that he is, has now added a
> check for this issue to recipe_sanity.bbclass.  If you have sanity
> checking enabled, this situation will now elicit a diagnostic along the
> lines of:
>
> NOTE: glibc-2.9: recipe_sanity: rename of variable 'RPROVIDES_${PN}-dev'
> to 'RPROVIDES_glibc-dev' overwrote existing value ' libc-dev' with
> 'libc6-dev virtual-libc-dev'. 
>
> which should make it easy to identify such issues in the future.  Thanks
> Chris!

Not a problem, happy to help.  It's worth noting, for anyone that hasn't 
tried recipe_sanity yet, that because it outputs so many messages, by 
default it's a standalone task, rather than being hooked into the normal 
build process the way sanity (config checks) and insane (packages / 
output checks) are.  Using it is explicit, INHERIT += "recipe_sanity", 
then bitbake -c recipe_sanity foo or bitbake -c recipe_sanity_all foo 
(to run against foo and its deps).

-Chris

Re: update-rc.d: don't add runtime dependency if not doing online package management; only add it to ${PN} in any case.

[Koen Kooi]

On 20-06-09 17:21, Christopher Larson wrote:
> Phil Blundell wrote:
>> On Fri, 2009-06-19 at 08:36 +0100, Phil Blundell wrote:
>>> On Wed, 2009-06-17 at 17:41 -0400, Denys Dmytriyenko wrote:
>>>> Any ideas why RDEPENDS_{PN} in "udev" recipe works, but
>>>> RDEPENDS_udev doesn't? It only happens with inherit
>>>> update-rc.d.bbclass, which also changes RDEPENDS_{PN}... I have the
>>>> same issue with my own recipes, which I need to fix similarly.
>>> It's a side effect of the way that overrides work in bitbake.
>>
>> ... and Chris Larson, being the great guy that he is, has now added a
>> check for this issue to recipe_sanity.bbclass. If you have sanity
>> checking enabled, this situation will now elicit a diagnostic along the
>> lines of:
>>
>> NOTE: glibc-2.9: recipe_sanity: rename of variable 'RPROVIDES_${PN}-dev'
>> to 'RPROVIDES_glibc-dev' overwrote existing value ' libc-dev' with
>> 'libc6-dev virtual-libc-dev'.
>> which should make it easy to identify such issues in the future. Thanks
>> Chris!
>
> Not a problem, happy to help. It's worth noting, for anyone that hasn't
> tried recipe_sanity yet, that because it outputs so many messages, by
> default it's a standalone task, rather than being hooked into the normal
> build process the way sanity (config checks) and insane (packages /
> output checks) are. Using it is explicit, INHERIT += "recipe_sanity",
> then bitbake -c recipe_sanity foo or bitbake -c recipe_sanity_all foo
> (to run against foo and its deps).

Why is it complaining about RDEPENDS? If some app needs external 
datafiles to run it sure as hell needs to set RDEPENDS.

regards,

Koen

Re: update-rc.d: don't add runtime dependency if not doing online package management; only add it to ${PN} in any case.

[Phil Blundell]

On Sat, 2009-06-20 at 19:19 +0200, Koen Kooi wrote:
> Why is it complaining about RDEPENDS? If some app needs external 
> datafiles to run it sure as hell needs to set RDEPENDS.

In almost all cases the app ought to be setting RDEPENDS_${PN}, not
RDEPENDS.  Otherwise the documentation, debug data and suchlike will end
up getting the same dependency, which is seldom useful.  The same goes
for most of the other R* variables.

p.