[yocto] Correctly setting a package-specific RDEPENDS

Paul Eggleton paul.eggleton at linux.intel.com
Wed Jun 5 09:27:26 PDT 2013


On Wednesday 05 June 2013 10:53:23 Jon Szymaniak wrote:
> I recently upgraded to the Dylan (9.0.0) release and am looking to
> clean up some QA issues associated with my RDEPENDS variables not
> being package-specific.
> 
> I'm a bit confused by a couple lines in the manual [1]:
> 
> "The names of the variables you list with RDEPENDS must be the names
> of other packages as listed in the PACKAGES variable. You should not
> list recipe names (PN)."

I think the mention of PN here is confusing. It's trying to explain that you 
should use package names and not recipe names, but perhaps the wording needs 
to be improved.

> It makes sense to me that you'd want to set the run-time deps on a
> per-package basis to avoid creating false-dependencies. However, I'm
> unsure as to how can simply not write RDEPENDS_${PN} in some cases.
> Furthermore, I feel like I'm not quite understanding what the
> consequences of using RDEPENDS_${PN} are.
> 
> Here's an example of what I'm trying to do -- perhaps someone will
> catch where I'm getting confused and offer some insight?
> 
> Let's say I have a program_a.bb and a program_b.bb. Both are simple
> recipes that compile and install ${D}/usr/bin/program_a and
> ${D}/usr/bin/program_b.
> 
> Because program_a forks and execs program_b, but otherwise does not
> depend upon it to compile, I thought I should place RDEPENDS_${PN} =
> "program_b " in program_a.bb.  However, this seems to violate the
> aforementioned snippet from the manual.

That is the expected usage; I guess the manual has confused you. All the QA 
warning is saying is you should do this:

RDEPENDS_${PN} = "somepackage"

and _not_ this:

RDEPENDS = "somepackage"

(The reason being, the latter would add a runtime dependency on "somepackage" 
to every package in the recipe's PACKAGES, which is almost never the desired 
result.)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre



More information about the yocto mailing list