[OE-core] Does recipe specific sysrooot (or whatelse in current oe) break native dependencies?

[Patrick Ohly]

On Mon, 2017-02-13 at 16:24 +0100, Patrick Ohly wrote:
> On Mon, 2017-02-13 at 15:36 +0100, Martin Jansa wrote:
> > Hi Andreas,
> > 
> > 
> > I think it's feature which was already there, but almost never
> > triggered (even in test-dependencies.sh tests), but with RSS it fails
> > reliably.
> > 
> > 
> > See:
> > http://lists.openembedded.org/pipermail/openembedded-core/2016-July/124435.html
> 
> That's not quite the same, if I understand it correctly. In that email,
> Richard was talking about "dependencies of that target are not needed
> and not installed" and used "quilt-native" and "compiler/toolchain" as
> example. In other words, if recipe foo DEPENDS on bar for getting foo
> compiled, that dependency on bar gets ignored when installing "foo" into
> the recipe specific sysroot because it shouldn't be needed anymore.
> 
> But the example here is a recipe foo which has a runtime dependency on
> bar, so bar must be installed in addition to foo, otherwise foo will not
> work.
> 
> This is where it gets tricky: do native recipes have RDEPENDS? They are
> not getting packaged, so I suppose not. One could collect all RDEPENDS_*
> values (regardless of the actual package), but that might be too broad
> (for example, when "packaging" the native recipe wouldn't even produce
> that package).

Apparently RDEPENDS do work, also for native recipes. Based on some
testing, it seems that all RDEPENDS are considered, even those that
refer to packages that would normally be empty, i.e. the sysroot
potentially contains more than strictly needed, but that shouldn't be a
problem.

Andreas, does adding RDEPENDS instead of (or, where needed, in addition
to) DEPENDS fix you problem?

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.