Switch to BlueZ 5.x as default Bluetooth stack

- Large release with over a month and 475 commits since 5.28;
- Internal GATT library received lots of updates;
- Fix for AVCTP key repeat timeout;
- Added support for the Multi Profile Specification (MPS).

Signed-off-by Cristian Iorga <[email protected]>

---
  meta/recipes-connectivity/bluez5/{bluez5_5.28.bb => bluez5_5.29.bb} | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

rename meta/recipes-connectivity/bluez5/{bluez5_5.28.bb => bluez5_5.29.bb} (88%)

meta/recipes-connectivity/bluez5/bluez5_5.29.bb renamed from meta/recipes-connectivity/bluez5/bluez5_5.28.bb +0 -0

similarity index 88%
rename from meta/recipes-connectivity/bluez5/bluez5_5.28.bb
rename to meta/recipes-connectivity/bluez5/bluez5_5.29.bb
index e816998..0fe8e7f 100644

I thought of 1.9 as the preparatory stage for complete removal of bluez4, so that in 2.0 it would be very easy to remove the support for bluez4. Continuing to have bluez5 added to DISTRO_FEATURES create the impression that BlueZ5 is still a second class citizen compared to BlueZ4, and it is not my intention to sustain this opinion via code.

I hereby standup for my solution. At the moment, we are 1to1. “We think” – Who are the others persons, Ross?

/Cristian

*From:*Burton, Ross [mailto:[email protected]]
*Sent:* Monday, April 6, 2015 12:41 AM
*To:* Iorga, Cristian
*Cc:* OE-core
*Subject:* Re: [OE-core] [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

On 3 April 2015 at 15:13, Cristian Iorga <[email protected] <mailto:[email protected]>> wrote:

-# Define a variable that expands to the recipe (package) providing core
-# bluetooth support on the platform:
+# Define a variable that expands to the recipe (package) providing +# core bluetooth support on the platform:
# "" if bluetooth is not in DISTRO_FEATURES
-# else "bluez5" if bluez5 is in DISTRO_FEATURES
-# else "bluez4"
+# else "bluez4" if bluez4 is in DISTRO_FEATURES
+# else "bluez5"

That wasn't the behaviour that 1.8 sets. We think we should continue to respect the bluez5 DISTRO_FEATURE and add it to DISTRO_FEATURES_BACKFILL.

Ross

On 04/06/2015 02:31 AM, Iorga, Cristian wrote:

I thought of 1.9 as the preparatory stage for complete removal of bluez4, so that in 2.0 it would be very easy to remove the support for bluez4. Continuing to have bluez5 added to DISTRO_FEATURES create the impression that BlueZ5 is still a second class citizen compared to BlueZ4, and it is not my intention to sustain this opinion via code.

I hereby standup for my solution. At the moment, we are 1to1. “We think” – Who are the others persons, Ross?

/Cristian

While I fully support moving to bluez5 and use it in all my images, I do think it's a bit abrupt to make it the default in the first stable release that provides a usable bluez5. On the other hand, Yocto's late to the bluez5 party and it's going to be harder to support bluez4 now.

Six of one; sign me up as weak support for delaying the move to default bluez5 until 1.10.

Just an opinion.

On 04/06/2015 02:31 AM, Iorga, Cristian wrote:

I thought of 1.9 as the preparatory stage for complete removal of bluez4, so that in 2.0 it would be very easy to remove the support for bluez4. Continuing to have bluez5 added to DISTRO_FEATURES create the impression that BlueZ5 is still a second class citizen compared to BlueZ4, and it is not my intention to sustain this opinion via code.

I hereby standup for my solution. At the moment, we are 1to1. “We think” – Who are the others persons, Ross?

/Cristian

While I fully support moving to bluez5 and use it in all my images, I do think it's a bit abrupt to make it the default in the first stable release that provides a usable bluez5. On the other hand, Yocto's late to the
bluez5 party and it's going to be harder to support bluez4 now.

Six of one; sign me up as weak support for delaying the move to default
bluez5 until 1.10.

Just an opinion.

Well,

1. Peter, Otavio: There is not a single doubt about moving to BlueZ 5 as default in 1.9;
2. The requested feedback was about the actual implementation;
3. Peter: " I do think it's a bit abrupt to make it the default in the first stable release that provides a usable bluez5."; The change is intended for 1.9,the release that will come in October 2015. Do you think that it is still abrupt? BlueZ5 is present in YP as an alternative BT stack from 1.7, it will still be a fully supported alternative in the (unreleased) 1.8 (as far as upstream goes as "fully supported", of course), it will the default BT stack in 1.9 (coming October 2015), while BlueZ 4 will still be supported as an obsolete, but still functional alternative; for 2.0 (why 1.10??), if that will be the name, all mechanisms for having BlueZ alternatives will be removed, and BlueZ 5 will be the only official supported BT stack. That's more than two years for a transition, is that too soon??

/Cristian

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Otavio Salvador
Sent: Monday, April 6, 2015 4:18 PM
To: Peter A. Bigot
Cc: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

Quoted 20 lines · Peter A. Bigot

On 04/06/2015 02:31 AM, Iorga, Cristian wrote:

I thought of 1.9 as the preparatory stage for complete removal of bluez4, so that in 2.0 it would be very easy to remove the support for bluez4. Continuing to have bluez5 added to DISTRO_FEATURES create the impression that BlueZ5 is still a second class citizen compared to BlueZ4, and it is not my intention to sustain this opinion via code.

I hereby standup for my solution. At the moment, we are 1to1. “We think” – Who are the others persons, Ross?

/Cristian

While I fully support moving to bluez5 and use it in all my images, I do think it's a bit abrupt to make it the default in the first stable release that provides a usable bluez5. On the other hand, Yocto's late to the
bluez5 party and it's going to be harder to support bluez4 now.

Quoted 5 lines

Six of one; sign me up as weak support for delaying the move to default
bluez5 until 1.10.

Just an opinion.

I prefer bluez5 default in 1.9 and removal in 2.0 (or 1.10). We shouldn't be support legacy without a very strong reason and if any member shows up to officially support bluez4 for longer we may drop its removal but bluez5 default should be done as soon as possible so we iron out regressions.

Quoted 18 lines · Cristian

Well,

1. Peter, Otavio: There is not a single doubt about moving to BlueZ 5 as default in 1.9;
2. The requested feedback was about the actual implementation;
3. Peter: " I do think it's a bit abrupt to make it the default in the first stable release that provides a usable bluez5."; The change is intended for 1.9,the release that will come in October 2015. Do you think that it is still abrupt? BlueZ5 is present in YP as an alternative BT stack from 1.7, it will still be a fully supported alternative in the (unreleased) 1.8 (as far as upstream goes as "fully supported", of course), it will the default BT stack in 1.9 (coming October 2015), while BlueZ 4 will still be supported as an obsolete, but still functional alternative; for 2.0 (why 1.10??), if that will be the name, all mechanisms for having BlueZ alternatives will be removed, and BlueZ 5 will be the only official supported BT stack. That's more than two years for a transition, is that too soon??

Sorry; I got confused about which numbers were which and where things are in the release cycle. I didn't consider bluez5 to be generally usable until the patches that were merged in February for what will be 1.8. Since both bluez4 and bluez5 will be available in 1.8, making the default bluez5 in 1.9 is fine, and removing bluez4 in what follows is fine. (I have no idea what version is intended to follow 1.9, but if it isn't some huge backwards-incompatible change I would expect it to be 1.10 rather than 2.0. That's just from the way I normally manage versioning myself.)

I have no objections to the technical approach in the patch (it's consistent with what I had in mind when I created that bbclass) but I'm not familiar with how DISTRO_FEATURES_BACKFILL is supposed to work so abstain from further comment.

On Mon, Apr 6, 2015 at 2:21 PM, Peter A. Bigot <[email protected] <mailto:[email protected]>> wrote:

On 04/06/2015 09:32 AM, Iorga, Cristian wrote:

Well,

1. Peter, Otavio: There is not a single doubt about moving to BlueZ 5 as default in 1.9;
2. The requested feedback was about the actual implementation;
3. Peter: " I do think it's a bit abrupt to make it the default in the first stable release that provides a usable bluez5."; The change is intended for 1.9,the release that will come in October 2015. Do you think that it is still abrupt? BlueZ5 is present in YP as an alternative BT stack from 1.7, it will still be a fully supported alternative in the (unreleased) 1.8 (as far as upstream goes as "fully supported", of course), it will the default BT stack in 1.9 (coming October 2015), while BlueZ 4 will still be supported as an obsolete, but still functional alternative; for 2.0 (why 1.10??), if that will be the name, all mechanisms for having BlueZ alternatives will be removed, and BlueZ 5 will be the only official supported BT stack. That's more than two years for a transition, is that too soon??

Sorry; I got confused about which numbers were which and where things are in the release cycle. I didn't consider bluez5 to be generally usable until the patches that were merged in February for what will be 1.8. Since both bluez4 and bluez5 will be available in 1.8, making the default bluez5 in 1.9 is fine, and removing bluez4 in what follows is fine. (I have no idea what version is intended to follow 1.9, but if it isn't some huge backwards-incompatible change I would expect it to be 1.10 rather than 2.0. That's just from the way I normally manage versioning myself.)

I have no objections to the technical approach in the patch (it's consistent with what I had in mind when I created that bbclass) but I'm not familiar with how DISTRO_FEATURES_BACKFILL is supposed to work so abstain from further comment.

Backfill lets you add features which become default in DISTRO_FEATURES even when a distro overrides DISTRO_FEATURES, unless they explicitly add them to DISTRO_FEATURES_BACKFILL_CONSIDERED.

Thank you. So, if I understand correctly, the effect of adding bluez5 to DISTRO_FEATURES_BACKFILL while keeping the current logic:

# bluetooth support on the platform:
# "" if bluetooth is not in DISTRO_FEATURES
# else "bluez5" if bluez5 is in DISTRO_FEATURES
# else "bluez4"

is that bluez5 becomes the default and is in DISTRO_FEATURES automatically, and it stays the default even if bluez4 is also in DISTRO_FEATURES unless somebody adds bluez5 to DISTRO_FEATURES_BACKFILL_CONSIDERED at which point bluez4 takes precedence.

If that understanding is correct, and reviewing
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-features-backfill,
it's not clear to me that it's the right approach. We're not backfilling "bluetooth", which remains optional and continues to control whether either "bluez4" or "bluez5" is relevant. We're changing the default provider of bluetooth services, something that I think can reasonably be changed between releases, and something that 1.8 already controls (via explicit specification of bluez4 or bluez5 in DISTRO_FEATURES).

Quoted 13 lines · Peter A. Bigot

Thank you. So, if I understand correctly, the effect of adding bluez5 to DISTRO_FEATURES_BACKFILL while keeping the current logic:

# bluetooth support on the platform:
# "" if bluetooth is not in DISTRO_FEATURES
# else "bluez5" if bluez5 is in DISTRO_FEATURES
# else "bluez4"

is that bluez5 becomes the default and is in DISTRO_FEATURES automatically, and it stays the default even if bluez4 is also in DISTRO_FEATURES unless somebody adds bluez5 to DISTRO_FEATURES_BACKFILL_CONSIDERED at which point bluez4 takes precedence.

Quoted 9 lines

If that understanding is correct, and reviewing
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-features-backfill,
it's not clear to me that it's the right approach. We're not backfilling "bluetooth", which remains optional and continues to control whether either "bluez4" or "bluez5" is relevant. We're changing the default provider of bluetooth services, something that I think can reasonably be changed between releases, and something that 1.8 already controls (via explicit specification of bluez4 or bluez5 in DISTRO_FEATURES).

My reasoning for backfilling bluez5 is that bluetooth.bbclass has a defined behaviour in 1.8:

if bluetooth in DF:
if bluez5 in DF:
return "bluez5"
else:
return "bluez4"
else:
return ""

There's no mention of a bluez4 DISTRO_FEATURE, just a "bluetooth" value to enable/disable Bluetooth in general, and the toggle between BlueZ 4 and 5 is the presence of a "bluez5" DISTRO_FEATURE.

We don't need to change the algorithm or create new DISTRO_FEATURE entries, as we have all the logic and items needed: by backfilling bluez5 into DISTRO_FEATURES we get the default switched, and distributions can flip back to bluez4 when upgrading to 1.9 by adding in meta-connectivity and wiping out bluez5 from DISTRO_FEATURES.

Or am I alone in thinking this is the best approach going forward?

For what it's worth, I'd agree with that. There's no need to change the logic.

for 2.0 (why 1.10??), if that will be the name, all mechanisms for having BlueZ alternatives will be removed, and BlueZ 5 will be the only official supported BT stack.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Otavio Salvador
Sent: Monday, April 6, 2015 4:18 PM
To: Peter A. Bigot
Cc: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

Quoted 20 lines · Peter A. Bigot

On 04/06/2015 02:31 AM, Iorga, Cristian wrote:

I thought of 1.9 as the preparatory stage for complete removal of bluez4, so that in 2.0 it would be very easy to remove the support for bluez4. Continuing to have bluez5 added to DISTRO_FEATURES create the impression that BlueZ5 is still a second class citizen compared to BlueZ4, and it is not my intention to sustain this opinion via code.

I hereby standup for my solution. At the moment, we are 1to1. “We think” – Who are the others persons, Ross?

/Cristian

While I fully support moving to bluez5 and use it in all my images, I do think it's a bit abrupt to make it the default in the first stable release that provides a usable bluez5. On the other hand, Yocto's late to the
bluez5 party and it's going to be harder to support bluez4 now.

Quoted 5 lines

Six of one; sign me up as weak support for delaying the move to default
bluez5 until 1.10.

Just an opinion.

I prefer bluez5 default in 1.9 and removal in 2.0 (or 1.10). We shouldn't be support legacy without a very strong reason and if any member shows up to officially support bluez4 for longer we may drop its removal but bluez5 default should be done as soon as possible so we iron out regressions.

Signature · 13 lines

Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

for 2.0 (why 1.10??), if that will be the name, all mechanisms for having BlueZ alternatives will be removed, and BlueZ 5 will be the only official supported BT stack.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Otavio Salvador
Sent: Monday, April 6, 2015 4:18 PM
To: Peter A. Bigot
Cc: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

Quoted 20 lines · Peter A. Bigot

On 04/06/2015 02:31 AM, Iorga, Cristian wrote:

I thought of 1.9 as the preparatory stage for complete removal of bluez4, so that in 2.0 it would be very easy to remove the support for bluez4. Continuing to have bluez5 added to DISTRO_FEATURES create the impression that BlueZ5 is still a second class citizen compared to BlueZ4, and it is not my intention to sustain this opinion via code.

I hereby standup for my solution. At the moment, we are 1to1. “We think” – Who are the others persons, Ross?

/Cristian

While I fully support moving to bluez5 and use it in all my images, I do think it's a bit abrupt to make it the default in the first stable release that provides a usable bluez5. On the other hand, Yocto's late to the
bluez5 party and it's going to be harder to support bluez4 now.

Quoted 5 lines

Six of one; sign me up as weak support for delaying the move to default
bluez5 until 1.10.

Just an opinion.

I prefer bluez5 default in 1.9 and removal in 2.0 (or 1.10). We shouldn't be support legacy without a very strong reason and if any member shows up to officially support bluez4 for longer we may drop its removal but bluez5 default should be done as soon as possible so we iron out regressions.

Signature · 13 lines

Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Well:
1. That's a thing for the future
2. Who will maintain support for bugs reported to BlueZ 4.x? It's a matter of resources.
3. "Projects using different Bluetooth implementations" is something different from switching from BZ4 to BZ5 and vice versa. We don’t support multiple Bluetooth stacks, but (incompatible!) variants of BlueZ. That's different. In the future, we will no longer support both, why complicate the code?

/Cristian Iorga
Yocto Project
Intel Corporation

-----Original Message-----
From: Martin Jansa [mailto:[email protected]]
Sent: Tuesday, April 7, 2015 1:55 PM
To: Iorga, Cristian
Cc: Otavio Salvador; Peter A. Bigot; Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

Quoted 3 lines · Cristian

for 2.0 (why 1.10??), if that will be the name, all mechanisms for having BlueZ alternatives will be removed, and BlueZ 5 will be the only official supported BT stack.

why would you remove mechanisms for having BlueZ alternatives?

Some projects are still using different bluetooth implementations and having the possibility to disable/replace bluez* is still useful.

Cheers,

Quoted 53 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Otavio Salvador
Sent: Monday, April 6, 2015 4:18 PM
To: Peter A. Bigot
Cc: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

Quoted 20 lines · Peter A. Bigot

On 04/06/2015 02:31 AM, Iorga, Cristian wrote:

I thought of 1.9 as the preparatory stage for complete removal of bluez4, so that in 2.0 it would be very easy to remove the support for bluez4. Continuing to have bluez5 added to DISTRO_FEATURES create the impression that BlueZ5 is still a second class citizen compared to BlueZ4, and it is not my intention to sustain this opinion via code.

I hereby standup for my solution. At the moment, we are 1to1. “We think” – Who are the others persons, Ross?

/Cristian

While I fully support moving to bluez5 and use it in all my images, I do think it's a bit abrupt to make it the default in the first stable release that provides a usable bluez5. On the other hand, Yocto's late to the
bluez5 party and it's going to be harder to support bluez4 now.

Quoted 5 lines

Six of one; sign me up as weak support for delaying the move to default
bluez5 until 1.10.

Just an opinion.

I prefer bluez5 default in 1.9 and removal in 2.0 (or 1.10). We shouldn't be support legacy without a very strong reason and if any member shows up to officially support bluez4 for longer we may drop its removal but bluez5 default should be done as soon as possible so we iron out regressions.

Signature · 13 lines

Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Signature · 1 line

Martin 'JaMa' Jansa     jabber: [email protected]

The aforementioned packageconfigs are just examples/guidelines, we added code for diverse recipes on a case by case scenario.

The aforementioned packageconfigs are just examples/guidelines, we added code for diverse recipes on a case by case scenario.

The only way this could be fixed is to remove the aforementioned guidelines.. Like I said, there are plenty of examples in the code.
Those packageconfigs where elaborated based on:
1. if a package has support for both BlueZ versions;
2. If not, usually only BlueZ 4 is supported;

Care to elaborate how I can fix them otherwise? I am open to suggestions.

(A friendly request: could you use interleaved posting style as described in the mailing list guidelines here:
https://wiki.yoctoproject.org/wiki/Community_Guidelines )

Quoted 7 lines · Cristian

The only way this could be fixed is to remove the aforementioned guidelines.. Like I said, there are plenty of examples in the code.
Those packageconfigs where elaborated based on:
1. if a package has support for both BlueZ versions;
2. If not, usually only BlueZ 4 is supported;

Care to elaborate how I can fix them otherwise? I am open to suggestions.

Sure, I can give concrete suggestions. This one I already gave in my first mail:

# Use this with:

#  inherit bluetooth
#  PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}"
#  PACKAGECONFIG[bluez4] = "--enable-bluez4,--disable-bluez4,bluez4"
#  PACKAGECONFIG[bluez5] = "--enable-bluez5,--disable-bluez5,bluez5"

When someone applies that example to a recipe that only supports one bluetooth implementation, then the example of course needs some adaptation, but that's ok. I think the example gives a clear enough idea how the BLUEZ variable is supposed to be used.

Note that if you anyway want to also give an example of how to deal with recipes that only support one bluetooth implmementation, I think this line should be changed:

  PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}"

The reason is that if the recipe only supports bluez4, for example, then PACKAGECONFIG should never include bluez5, but that line will put bluez5 to PACKAGECONFIG if the distro's chosen bluetooth implementation is bluez5. I suppose that doesn't actually break anything, but I don't think it's a good idea to recommend adding garbage to PACKAGECONFIG.

This would be more appropriate for recipes that only support bluez4:

#  inherit bluetooth
#  PACKAGECONFIG ??= "${@bb.utils.contains('BLUEZ', 'bluez4', 'bluez4, '', d}"
#  PACKAGECONFIG[bluez4] = "--enable-bluez4,--disable-bluez4,bluez4"

Quoted 5 lines · Tanu Kaskinen

This would be more appropriate for recipes that only support bluez4:

#  inherit bluetooth
#  PACKAGECONFIG ??= "${@bb.utils.contains('BLUEZ', 'bluez4', 'bluez4, '', d}"
#  PACKAGECONFIG[bluez4] = "--enable-bluez4,--disable-bluez4,bluez4"

The last example isn't correct, because you still need to respect 'bluetooth' in 'DISTRO_FEATURES' before enabling whatever is in BLUEZ variable.

Quoted 7 lines · Martin Jansa

Quoted 5 lines · Tanu Kaskinen

This would be more appropriate for recipes that only support bluez4:

#  inherit bluetooth
#  PACKAGECONFIG ??= "${@bb.utils.contains('BLUEZ', 'bluez4', 'bluez4, '', d}"
#  PACKAGECONFIG[bluez4] = "--enable-bluez4,--disable-bluez4,bluez4"

Quoted 3 lines

The last example isn't correct, because you still need to respect 'bluetooth' in 'DISTRO_FEATURES' before enabling whatever is in BLUEZ variable.

BLUEZ is empty if 'bluetooth' is not in DISTRO_FEATURES, so my example should work fine.

Quoted 8 lines · Tanu Kaskinen

Quoted 7 lines · Martin Jansa

Quoted 5 lines · Tanu Kaskinen

This would be more appropriate for recipes that only support bluez4:

#  inherit bluetooth
#  PACKAGECONFIG ??= "${@bb.utils.contains('BLUEZ', 'bluez4', 'bluez4, '', d}"
#  PACKAGECONFIG[bluez4] = "--enable-bluez4,--disable-bluez4,bluez4"

Quoted 6 lines

Quoted 3 lines

The last example isn't correct, because you still need to respect 'bluetooth' in 'DISTRO_FEATURES' before enabling whatever is in BLUEZ variable.

BLUEZ is empty if 'bluetooth' is not in DISTRO_FEATURES, so my example should work fine.

The default value is, but that doesn't ensure that user has different value set in local.conf and suddenly his bluetooth-less distro configuration is trying to enable bluez* support in some component.

So for consistency sake you should respect bluetooth in DISTRO_FEATURES (like in the previous example).