From: Phil Blundell <pb@pbcl.net>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: RDEPENDS_${PN} and virtclass-native
Date: Wed, 25 May 2011 18:01:21 +0100 [thread overview]
Message-ID: <1306342881.2525.258.camel@phil-desktop> (raw)
By way of displacement activity to avoid actually fixing my perl
compilation problem, it occurred to me to investigate why perl was
getting dragged into a micro-base-image build in the first place. The
culprit turns out to be imake, which does:
RDEPENDS_${PN} = "perl xproto"
and is then BBCLASSEXTENDed to imake-native (which in turn is pulled in
by way of prelink-native and transfig-native).
Now, leaving aside the question of whether it is reasonable for prelink
to be depending on transfig, it is clearly wrong for the -native version
of imake to be depending on perl. It seems that native.bbclass makes
some effort to rewrite plain RDEPENDS to the -native version, but it
doesn't apply the same tactics to RDEPENDS_${PN} or any such. (And, in
fact, rewriting plain RDEPENDS is probably futile since few if any
recipes are going to be setting it.)
Obviously I can fix this by just setting RDEPENDS_virtclass-native in
the recipe, and that's what I've done in my local tree. But I wonder if
a better solution would be for native.bbclass to be slightly more
adventurous about rewriting these things for itself.
p.
next reply other threads:[~2011-05-25 17:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-25 17:01 Phil Blundell [this message]
2011-05-25 17:03 ` RDEPENDS_${PN} and virtclass-native Chris Larson
2011-05-25 23:02 ` Richard Purdie
2011-05-25 23:08 ` Khem Raj
2011-05-26 10:15 ` Phil Blundell
2011-05-26 0:00 ` Richard Purdie
2011-05-26 0:11 ` Chris Larson
2011-05-26 0:59 ` Richard Purdie
2011-05-31 23:04 ` Richard Purdie
2011-05-26 10:27 ` Phil Blundell
2011-05-31 11:29 ` [PATCH] prelink: remove dependency on transfig-native Phil Blundell
2011-05-31 11:46 ` Richard Purdie
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=1306342881.2525.258.camel@phil-desktop \
--to=pb@pbcl.net \
--cc=openembedded-core@lists.openembedded.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox