* proper way to express dependencies from meta-oe to meta-gnome?
@ 2013-08-05 13:43 Robert P. J. Day
2013-08-05 14:04 ` Martin Jansa
0 siblings, 1 reply; 2+ messages in thread
From: Robert P. J. Day @ 2013-08-05 13:43 UTC (permalink / raw)
To: OpenEmbedded Development mailing list
for the entertainment value, while building for the beaglebone
black, i did:
$ bitbake -c fetchall world
and got:
ERROR: Nothing RPROVIDES 'gvfs' (but
/home/rpjday/oe/dist/layers/meta-openembedded/meta-oe/recipes-support/tracker/tracker_0.14.2.bb
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'gvfs' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['gvfs']
ERROR: Required build target 'tracker' has no buildable providers.
Missing or unbuildable dependency chain was: ['tracker', 'gvfs']
and it's easy enough to see that, yes, tracker RDEPENDS on gvfs, which
is defined in meta-gnome which is a layer i'm not including.
so what is the preferred way to resolve stuff like that? is one
simply supposed to *know* (or check) that tracker requires gvfs? or
read the diagnostics and adjust accordingly?
given that tracker's home page is at gnome.org, would it make more
sense for tracker to be part of meta-gnome instead of meta-oe? just
trying to understand how recipes are distributed among the layers.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: proper way to express dependencies from meta-oe to meta-gnome?
2013-08-05 13:43 proper way to express dependencies from meta-oe to meta-gnome? Robert P. J. Day
@ 2013-08-05 14:04 ` Martin Jansa
0 siblings, 0 replies; 2+ messages in thread
From: Martin Jansa @ 2013-08-05 14:04 UTC (permalink / raw)
To: openembedded-devel
[-- Attachment #1: Type: text/plain, Size: 1523 bytes --]
On Mon, Aug 05, 2013 at 09:43:34AM -0400, Robert P. J. Day wrote:
>
> for the entertainment value, while building for the beaglebone
> black, i did:
>
> $ bitbake -c fetchall world
>
> and got:
>
> ERROR: Nothing RPROVIDES 'gvfs' (but
> /home/rpjday/oe/dist/layers/meta-openembedded/meta-oe/recipes-support/tracker/tracker_0.14.2.bb
> RDEPENDS on or otherwise requires it)
> NOTE: Runtime target 'gvfs' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['gvfs']
> ERROR: Required build target 'tracker' has no buildable providers.
> Missing or unbuildable dependency chain was: ['tracker', 'gvfs']
>
> and it's easy enough to see that, yes, tracker RDEPENDS on gvfs, which
> is defined in meta-gnome which is a layer i'm not including.
>
> so what is the preferred way to resolve stuff like that? is one
> simply supposed to *know* (or check) that tracker requires gvfs? or
> read the diagnostics and adjust accordingly?
>
> given that tracker's home page is at gnome.org, would it make more
> sense for tracker to be part of meta-gnome instead of meta-oe? just
> trying to understand how recipes are distributed among the layers.
As nothing else in meta-oe depends on tracker, easiest way to
resolve this is to move tracker to meta-gnome.
With optional dependencies it's common to use PACKAGECONFIG and let
people enable PACKAGECONFIG option only when they also have required
layer.
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2013-08-05 14:04 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-08-05 13:43 proper way to express dependencies from meta-oe to meta-gnome? Robert P. J. Day
2013-08-05 14:04 ` Martin Jansa
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.