Re: Does recipe specific sysrooot (or whatelse in current oe) break native dependencies?

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Mon, 2017-02-13 at 16:45 +0100, Andreas Müller wrote:
> On Mon, Feb 13, 2017 at 4:24 PM, Patrick Ohly <patrick.ohly@intel.com
> > wrote:
> > On Mon, 2017-02-13 at 15:36 +0100, Martin Jansa wrote:
> > > 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-Ju
> > > ly/124435.html
> Richard wrote
> > 
> > What it does mean is that any recipe needing a -native recipe to
> > build
> > should list it in DEPENDS directly, not rely on other dependencies
> > to
> > pull it in for them. This applies to pkgconfig-native, intltool-
> > native
> > and also to wayland-native.
> This answers my question and leaves me unhappy - I am out for a
> while..

To be clear, you can't depend on the build dependencies of some other
recipe to be available to your recipe just because you DEPEND on it.

The RDEPENDS issue that Patrick mentions is a different one, its a
valid recipe markup problem we have processing RDEPENDS information in
the native case.

The kind of indirection that Andreas sounds like he's been relying on
may have happened to work most of the time but I'd bet there were ways
that a semi populated sstate cache could break it.

With RSS, we encoded the sstate behaviour in a deterministic way so the
races that might have happened now do happen all the time.

The simple solution for repetitive dependencies and shortcuts is just
to create a class, list all the things you need in there and then
inherit the class in the recipes as appropriate. I'd hope that isn't
too hard to sort out...

Cheers,

Richard