Hi Bastien, On Tue, Jul 22, 2025 at 10:10 AM Bastien Nocera <hadess@xxxxxxxxxx> wrote: > > On Tue, 2025-07-22 at 14:26 +0100, Francesco Giancane wrote: > > Hello! > > > > On 22/07/2025 13:54, Bastien Nocera wrote: > > > On Mon, 2025-07-21 at 16:22 +0100, Francesco Giancane wrote: > > > > Hi, > > > > > > > > I am posting this patch series to better decouple `bluetoothd` > > > > daemon > > > > and `libbluetooth`, as mentioned in the subject. > > > > > > > > I am introducing this change to make new BlueZ more granular. > > > > This will allow more control on which components are actually > > > > selected > > > > to build. > > > > > > > > Major use case for this change is fixing circular dependencies > > > > when > > > > bootstrapping new builds where the whole build root is to be > > > > recreated > > > > (e.g. Yocto Project). > > > > In these scenarios, to have Bluetooth support enabled in Python, > > > > `libbluetooth` is required at build time to be present but the > > > > direct > > > > chain of dependencies would require a Python installation > > > > available, > > > > thus introducing circular dependency. > > > > Separating the library and header files from the rest allows > > > > build > > > > systems to break the dependency loop. > > > FWIW, I'm currently porting bluez to meson (currently stuck on > > > porting > > > ell with its gazillion of SSL certificate tests), which would make > > > python a pre-requirement for bluez (if meson ended up being the > > > only > > > build system). > > > > > > What part of Python itself has Bluetooth support? Wouldn't it also > > > be > > > possible to make that part of Python separate so it can be built > > > after > > > bluez? > > > > Python uses autoconf to detect compile-time dependencies. > > > > They implemented Bluetooth network management with standard socket() > > calls. > > > > This code path is enabled at compile time only if it detects > > bluetooth.h > > header. > > > > So for python to support Bluetooth in std library, libbluetooth > > should > > be already deployed. > > > > With this current patch series I posted, you can build a "lite" > > version > > of bluez to ship just enough > > > > the library and the headers so that python can have bluetooth support > > (building a full BlueZ package requires > > > > python too... hence the circular dependency). > > Right, so you're trying to do: > - bluez (lib and headers only) > - python (with Bluetooth support) > - bluez (full) > > And if meson were the only build system, you'd need to do: > - python (without Bluetooth support) > - bluez (full) > - python (with Bluetooth support) > > I guess having a minimal uapi header upstream would allow to do: > - python (with Bluetooth support) > - bluez (full) +1 > Definitely the best option. > > I think it might be best to only migrate to the upstream kernel uapi > the minimum needed to build Python with Bluetooth support, and extend > it as needed afterwards. What sort of Bluetooth support does Python have built-in? I thought that would use D-Bus like pybluez, etc, but perhaps it has some HCI and SDP functionality that came built-in with libbluetooth, but its usability is very limited without the daemon, in fact it probably not really recommended to do HCI or SDP on the application side nowadays since we now have management interface that abstract HCI and SDP is sort of legacy with LE Audio catching up with BR/EDR that will probably be deprecated at some point, so perhaps we shall work with Python folks to drop the usage of libbluetooth completely once we have the UAPI headers. > In the short-term, why not apply your bluez patches to your bluetoothd > recipe rather than upstream? That should also motivate developers to > land the "correct" fix upstream ;) Yeah, going with intermediate solution will sort of introduce a new dependency in the form of lib only support which will serve as excuse not to adopt UAPI as soon as they are available. > Cheers > > > > > Francesco > > > > > > > > > `--enable-bluetoothd` flag is added to the `configure` script and > > > > it is keeping the same behavior as other flags. > > > > > > > > Francesco Giancane (3): > > > > configure.ac: introduce `--enable-bluetoothd` flag > > > > Makefile.am: build `bluetoothd` if enabled > > > > README: document `--enable-bluetoothd` flag > > > > > > > > Makefile.am | 8 ++++++++ > > > > README | 14 ++++++++++++++ > > > > configure.ac | 4 ++++ > > > > 3 files changed, 26 insertions(+) > -- Luiz Augusto von Dentz
