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 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.