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

[Peter A. Bigot]

On 11/12/2014 05:06 AM, Richard Purdie wrote:
> 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.

You raise some good questions.  I'll come back to whether the name for 
"whatever provides build-time support for bluetooth" should be spelled 
"virtual/bluez" or something else.

I think using bluez5 (bluetooth5) and bluez4 (bluetooth) as distinct 
PACKAGECONFIG options would be a mistake, because it propagates the 
assumption that "bluetooth" in Linux is a multivalent concept. Bluetooth 
in Linux is bluez.  Bluez is bluez5.  Work stopped on bluez4 over two 
years ago, and nobody's come up with third alternative.  IMO, the 
packageconfig option should be "bluetooth", not "bluez*".  I did see 
what Chris Larson wrote in 
http://lists.openembedded.org/pipermail/openembedded-core/2014-March/091008.html 
but I just don't see the value in adding extra infrastructure for a 
bunch of options that either don't exist now or won't exist in the near 
future.

Of the roughly 16 recipes I had to touch, only one (pulseaudio) clearly 
distinguishes between bluez4 and bluez5 when being configured, and I 
suspect that's just to simplify transition.  The others either figure 
out which version they were given and use it, or will only work with one 
or the other.  They all at least build with virtual/bluez, though they 
might internally disable bluetooth support or fail at runtime if bluez5 
is what's available.  (Qt 5.4 will support bluez5; it's unclear to me 
whether it still supports bluez4.)

There are and will continue to be certain recipes that will never move 
beyond bluez4, because they're no longer maintained or nobody has found 
it worthwhile (obex stuff) or a priority (headset stuff) to re-implement 
the functionality they depend on under the new API. So we do need to 
support using bluez4 and bluez5 as alternatives. But most recipes don't 
seem to care who provides "bluetooth", and if it's currently bluez4 and 
the package is maintained it'll eventually become bluez5.  Thus 
"virtual/bluez".  AFAIK the libbluetooth API is unchanged; it's the dbus 
API that's different.  If consensus is to substitute something like 
"distro/bluez" instead of "virtual/bluez" to remove the implication it's 
completely API-equivalent that'd be fine, but I think we do need some 
name to serve that role without putting the conditional in every recipe 
that might reference the selected bluetooth solution.

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

Using bluez4 and bluez5 in DISTRO_FEATURES makes some sense, as a 
parallel to systemd vs sysvinit.  (I don't like "bluetooth5" because 
there's no such thing; since we already have "bluetooth" I'd suggest 
making "bluez4" the canonical spelling and interpreting "bluetooth" in 
the absence of "bluez5" as being an alias for "bluez4".)  This provides 
a way to set the PREFERRED_PROVIDER for "distro/bluez" and possibly to 
set the PNBLACKLISTs to exclude the recipes that are not appropriate 
under bluez4.

Then we just use "distro/bluez" instead of "virtual/bluez" in all the 
recipes.

Is that any closer to acceptable?

Peter

>
> We'll of course still need VIRTUAL-RUNTIME_bluez but that isn't a new
> problem.
>
> Does that approach work for people?
>
> Cheers,
>
> Richard
>