Re: [Buildroot] [PATCH] package/bluez5_utils: expose more disable options

[Arnout Vandecappelle <arnout@mind.be>]

On 26/07/2021 23:07, Thomas Petazzoni wrote:
> Hello,
> 
> (Yann, Arnout, Peter: question for you below.)
> 
> On Mon, 26 Jul 2021 22:12:42 +0200
> Michael Nosthoff via buildroot <buildroot@busybox.net> wrote:
> 
>> BlueZ builds a lot of Classic BT profiles by default but allows
>> to disable them. This is especially handy when only BLE is needed
>> and enabled in the kernel.
>>
>> Otherwise this yields warnings like this on bootup:
>>
>>  profiles/network/bnep.c:bnep_init() kernel lacks bnep-protocol support
>>  src/plugin.c:plugin_init() System does not support network plugin
>>
>> Also it allows to disable btmon which should not be needed on
>> production systems and is ~800KB in size.
>>
>> Expose those options but default to 'y' to no break existing
>> configurations.
>>
>> Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
>> ---
>>  package/bluez5_utils/Config.in       | 36 ++++++++++++++++++++++++
>>  package/bluez5_utils/bluez5_utils.mk | 41 ++++++++++++++++++++++++++++
>>  2 files changed, 77 insertions(+)
> 
> Applied to master, thanks.
> 
> Arnout, Peter, Yann: in order to preserve backward compatibility,
> Michael has created those new options with a "default y". However,
> while it keeps backward compatibility, it also means that all new users
> will get a more bloated bluez_utils installation than is probably
> necessary. Should we break our backward compatibility rule here and
> drop the "default y" on those new options ?

 I know from experience that that's the kind of tricky changes that can make it
annoying to update Buildroot.

 Assuming you select bluez5_utils from menuconfig, having a default y is not
much of a problem in practice. However, bluez5_utils is also selected
automatically by a couple of packages [*] - in that case, the user doesn't see
the suboptions so isn't aware that they can disable them.

 So yes, there are good reasons to prefer default n. But then I think we should
think of a way to smoothen things for people who want to update buildroot. Here
are a few ideas:

- Just mention it in CHANGES.

- Extend the documentation in docs/manual/migrating.txt with this kind of
information. That would make that chapter quite a bit bigger over time, and
perhaps looking over the notes for each 3-month update is going to be quite a
bit of work.

- Write a tool that detects relevant changes. You'd run it in the newer
buildroot tree on the old .config. It would detect for example that the .config
has BR2_PACKAGE_BLUEZ5_UTILS set but BR2_PACKAGE_BLUEZ5_UTILS_MONITOR is not
mentioned at all in the .config, and write something about it. This tool could
also replace Config.in.legacy.

- Like above, but implemented directly in kconfig.

- Independent of this, a feature that I sometimes miss is a tool that tells me
which packages (and kernel and bootloader) are enabled but not selected by
another package (like an interactive defconfig, but showing everything that is
'yes' instead of everything that is default). Indeed, when you're developing,
you tend to enable a bunch of packages that you're later going to remove again.
Removing the package itself isn't much of a bother, but they often pull i
dependencies that you don't actually need. The way I solve this is that I edit
the defconfig instead of using menuconfig - not exactly user friendly. Anyway,
if such a tool existed, then it would be much more obvious that a bunch of
bluez5_utils plugins are enabled so the default y is less harmful.


 Given that all of these ideas except the first two are a lot of work, we'll
probably end up with the first two :-)


[*] BTW, did someone check if those packages that select bluez5_utils now should
be updated to select the appropriate plugin? Probably not - I imagine cwiid (for
the wiimote) for example needs the HID plugin, and the gstreamer plugin needs
A2DP and/or AVDP. Runtime dependencies, of course, so we'll never know until
someone actually complains about it.


 Regards,
 Arnout
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot