From: Martin Jansa <martin.jansa@gmail.com>
To: Patrick Ohly <patrick.ohly@intel.com>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: Does recipe specific sysrooot (or whatelse in current oe) break native dependencies?
Date: Mon, 13 Feb 2017 16:32:45 +0100 [thread overview]
Message-ID: <20170213153245.GC3280@jama> (raw)
In-Reply-To: <1486999455.13854.241.camel@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]
On Mon, Feb 13, 2017 at 04:24:15PM +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.
I'm not sure if it's the same or not, but back then I got very rarely
missing dependency on wayland-native or qtwayland-native, now with RSS I
got 20-30 recipes failing because of missing dependency on
wayland-native, qtwayland-native or qtbase-native to stage the scanner,
moc and other native tools in recipe-sysroot-native.
And Andreas issues look similar to that.
> 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).
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]
next prev parent reply other threads:[~2017-02-13 15:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-13 0:26 Does recipe specific sysrooot (or whatelse in current oe) break native dependencies? Andreas Müller
2017-02-13 13:47 ` Andreas Müller
2017-02-13 14:36 ` Martin Jansa
2017-02-13 15:15 ` Andreas Müller
2017-02-13 15:24 ` Patrick Ohly
2017-02-13 15:32 ` Martin Jansa [this message]
2017-02-13 15:37 ` Patrick Ohly
2017-02-13 15:52 ` Max Krummenacher
2017-02-13 15:45 ` Andreas Müller
2017-02-13 18:05 ` Richard Purdie
2017-02-13 18:17 ` Andreas Müller
2017-03-05 0:55 ` Andreas Müller
2017-02-13 17:03 ` Patrick Ohly
2017-02-13 17:06 ` Patrick Ohly
2017-02-14 10:26 ` Patrick Ohly
2017-02-19 22:26 ` Richard Purdie
2017-02-20 14:14 ` Patrick Ohly
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170213153245.GC3280@jama \
--to=martin.jansa@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=patrick.ohly@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.