[OE-core] [RFC 07/14] qt-mobility: switch to virtual/bluez

[Richard Purdie]

On Mon, 2014-11-10 at 15:13 -0600, Peter A. Bigot wrote:
> Signed-off-by: Peter A. Bigot <pab at pabigot.com>
> ---
>  meta/recipes-qt/qt4/qt-mobility_1.2.0.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-qt/qt4/qt-mobility_1.2.0.inc b/meta/recipes-qt/qt4/qt-mobility_1.2.0.inc
> index ae1769d..61b5281 100644
> --- a/meta/recipes-qt/qt4/qt-mobility_1.2.0.inc
> +++ b/meta/recipes-qt/qt4/qt-mobility_1.2.0.inc
> @@ -3,7 +3,7 @@ DEPENDS = "gstreamer util-linux"
>  
>  PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'pulseaudio', 'pulseaudio', '', d)} \
>                     ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluetooth', '', d)}"
> -PACKAGECONFIG[bluetooth] = ",,bluez4"
> +PACKAGECONFIG[bluetooth] = ",,virtual/bluez"
>  PACKAGECONFIG[pulseaudio] = ",,pulseaudio"
>  
>  LICENSE = "LGPLv2.1"

I think its examples like this where I start to get concerned. I don't
think the problem we're trying to solve here (bluez4 verses bluez5) maps
well to the way virtual/* is meant to work.

virtual/* things are meant to be equivalent, it doesn't matter which
ones the recipe builds against, it works. A compiler or a kernel are
good examples. That isn't the case for v4 verses v5 since some software
works with 4, some with 5 and some with both.

So what do we need to do?

I think this needs a:

PACKAGECONFIG[bluetooth5] = ",,bluez5"

and then we add a bluetooth5 DiSTRO_FEATURE and a:

                    ${@bb.utils.contains('DISTRO_FEATURES',
'bluetooth5', 'bluetooth5', '', d)}"

We could probably use a mechanism to flag two options as conflicting,
e.g. both bluetooth and bluetooth5 in DISTRO_FEATURES or in
PACKAGECONFIG however that is a separate issue.

We'll of course still need VIRTUAL-RUNTIME_bluez but that isn't a new
problem.

Does that approach work for people?

Cheers,

Richard