Re: confusion about DEPENDS vs RDEPENDS

[Paul Eggleton <paul.eggleton@linux.intel.com>]

Hi Hans,

On Wednesday 28 August 2013 17:08:41 Hans Beckérus wrote:
> Hi, I am a little bit confused about how to handle these two and what
> they are supposed to solve. I have so far never used RDEPENDS but only
> DEPENDS.

DEPENDS means a build-time dependency i.e. between recipes, RDEPENDS means a 
runtime dependency i.e. between packages. It is worth noting though that an 
explicitly stated RDEPENDS will cause bitbake to actually build the recipe 
providing the package named in the RDEPENDS value, just at a different time. To 
explain exactly what each of these do:

* DEPENDS = "b" in recipe "a" will translate to a's do_configure task depending 
on recipe b's do_populate_sysroot task, so that anything recipe b puts into 
the sysroot is available for when a configures itself.

* RDEPENDS_${PN} = "b" in recipe "a" will translate to a's do_build task 
depending on recipe b's do_package_write task, so that the package file b is 
available when the output for a has been completely built (of course assuming 
that recipe b produces a package called "b", which it will with the default 
value of PACKAGES). More importantly it will also ensure that package "a" is 
marked as depending on "b" in a manner understood by the package manager being 
used e.g. rpm / opkg / dpkg.

> But I am also having severe problems when building a rootfs image when
> one of my user space libraries are changed from eg. libfoo.so.1 to
> libfoo.so.3. Even though all my packages that have dependencies to it
> includes it in a DEPENDS.
> 
> The error I get during rootfs build is:
> | Computing transaction...error: Can't install
> 
> someapp-1.0-r0@cortexa9_vfp: no package provides libfoo.so.1
> 
> But there is no libfoo.so.1 in my sysroot, it has been replaced by
> libfoo.so.3. I know for sure that 'someapp' was rebuilt, but still I got
> the error message. What do seem to help is to force a fetch of 'someapp'
> and then rebuild which sort of indicates that some garbage was left behind.
> But having a package listed in DEPENDS will not force a new fetch if I am
> not mistaken.

By default, if recipe "foo" changes and it is mentioned in the "someapp" 
recipe's DEPENDS, then someapp's do_configure and all tasks that depend upon it 
will be re-executed next time it is called for i.e. you explicitly build 
someapp or build an image that contains it or some other recipe that depends 
upon it. The fact that you are getting the behaviour described suggests that 
this is either not happening, or more likely it is not having the desired 
effect; e.g. if internally someapp's build system doesn't drop or invalidate 
all of its  build output when it is reconfigured then you will get this kind of 
behaviour. Setting up B (the directory in which a recipe's source code is 
built) separate to S (the directory in which the recipe's source code has been 
unpacked to) can help with this since if they are separate, our build system 
will know it can delete B before re-executing do_compile after do_configure and 
you'll never have stale build output. Being able to set this up however is 
highly dependent on the software being built by the individual recipe; some 
lend themselves to this and others don't.
 
> Have I been using the DEPENDS variable incorrectly? Would it make a
> difference if I used RDEPENDS instead?

RDEPENDS would not be appropriate in this situation, since we're talking about 
a build-time dependency.

Hope that helps.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre