From: Phil Blundell <pb@pbcl.net>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: RDEPENDS_${PN} and virtclass-native
Date: Thu, 26 May 2011 11:27:12 +0100 [thread overview]
Message-ID: <1306405632.2525.306.camel@phil-desktop> (raw)
In-Reply-To: <1306342881.2525.258.camel@phil-desktop>
On Wed, 2011-05-25 at 18:01 +0100, Phil Blundell wrote:
> Now, leaving aside the question of whether it is reasonable for prelink
> to be depending on transfig,
This also seemed worthy of a bit of further investigation. Here's what
I found out:
The dependency on transfig-native was added by commit
2fbcf1419909cf2840d56bf461ab04f8298f14c6, on the grounds that fig2dev is
needed to build the prelink documentation. Which seems reasonable
enough on the face of it, except that (a) we probably don't want to
build documentation (or depend on transfig-native) for the -native
package; and (b) the documentation build had already been disabled, for
both native and non-native prelink, three days previously by commit
66e6a9798e5462a6cd8dce22a400b81f1dcae88b.
So, right now, it seems that the dependency on transfig-native is
entirely redundant and I think commit
66e6a9798e5462a6cd8dce22a400b81f1dcae88b can/should be reverted. In the
longer term it seems like switching the documentation back on for the
non-native prelink would be a good thing to do.
p.
next prev parent reply other threads:[~2011-05-26 10:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-25 17:01 RDEPENDS_${PN} and virtclass-native Phil Blundell
2011-05-25 17:03 ` 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 [this message]
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=1306405632.2525.306.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