Open alcir opened 4 years ago
Umm where does bluepy use it's own version? I don't see how a python package could feasibly ship their own bluez.
For example the Arch package https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/python-bluepy
I'm fairly certain it always uses the system bluez.
I do see where the Arch package cleans up a bluez-src. It seems just removing that is enough.
Sorry but since I'm not too practical with sources etc. my terminology could be incorrect.
I mean. In order to build the python package, bluepy doesn't use C headers and so on provided by system, but the source package includes bluez sources, and the Makefile points to them. Or I'm wrong?
For that I'm not sure. I've had no issues with the packaging on Arch at least. bluez updates and everything is fine.
bluepy uses a copy of some source files from the BlueZ project to build a C language executable, bluepy-helper
, which is a shim between Python and the kernel's Bluetooth interface. It does not build or install any binaries which are the same as what the BlueZ package provides - so at no point would you have a "bluepy" and a "system" version of the same thing on your disk.
Note that there isn't a realistic way to "use the system's BlueZ" - BlueZ itself provides various command line executables and daemons, but there isn't a library or low-level interface suitable for calling from Python. (I looked at the D-Bus interface but at the time it was very incomplete, and its availability is likely to vary a lot between distributions).
but there isn't a library or low-level interface suitable for calling from Python
The libbluetooth.so
library and associated headers that is packaged in bluez-libs-devel (on Fedora/RHEL) is not suitable?
Hello. I would like to package bluepy for Fedora. Fedora doesn't allow to bundle a release of bluez in the package. It should use the system release of bluez.
There is a way to provide a method to compile bluepy using the system version of bluez?