From Fedora Project Wiki
m (Fix a typo)
m (→‎Owner: List me as an owner)
Line 9: Line 9:
This should link to your home wiki page so we know who you are.  
This should link to your home wiki page so we know who you are.  
-->
-->
* Name: [[User:hadess| Bastien Nocera]]
* Name: [[User:hadess| Bastien Nocera]], [[User:kalev| Kalev Lember]]
* Email: bnocera@redhat.com
* Email: bnocera@redhat.com, kalevlember@gmail.com
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)

Revision as of 21:45, 10 August 2013

Migrate to Bluez 5

Summary

Fedora currently ships with Bluez version 4. In Fedora 20, we are going to switch to Bluez 5.

Owner

Current status

  • Targeted release: Fedora 20
  • Last updated: 2013-07-02
  • Tracker bug: <will be assigned by the Wrangler>

Detailed Description

In Fedora 20, we'll be using BlueZ 5.x to manage Bluetooth devices.

Bluez5 uses a D-Bus API that's not compatible with Bluez4 and as such, management applications and a number of libraries and daemons will need to be ported.

LWN introduction to BlueZ 5: http://lwn.net/Articles/531133/

BlueZ 5 porting guide: http://www.bluez.org/bluez-5-api-introduction-and-porting-guide/

Benefit to Fedora

This keeps the Bluetooth stack in Fedora up to date. Bluez 4 is no longer maintained upstream; switching to Bluez 5 ensures we can get all the latest upstream bug fixes and enhancements.

Scope

  • Proposal owners:

For GNOME 3.10 (due September 2013), Gustavo Padovan and Bastien Nocera are going to be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ 5.

  • Other developers:

Bluez4 and Bluez5 are not parallel-installable, and incompatible, so other applications relying on Bluez4 will need to be ported by their respective maintainers.

  • Release engineering:

No release engineering coordination required.

  • Policies and guidelines:

No changes needed in the packaging guidelines.

Upgrade/compatibility impact

BlueZ ships a daemon and provides two main interfaces for applications to use it:

libbluetooth shared library

The library ABI hasn't changed and the soname in 5.x is still the same as was in 4.x: libbluetooth.so.3, so the impact should be minimal. Everything should be able to continue working without needing even a simple rebuild.

org.bluez D-Bus API

Not all packages that use the org.bluez D-Bus service have a dependency on the bluez package. This makes it hard to find all the consumers; there's probably a number of applications that use bluez via D-Bus without requiring it as a dependency if the functionality isn't the main one, so there's likely going to be other impacted packages.

  • blueman (Status: needs porting to BlueZ 5)
  • gnome-bluetooth (Status: ported)
  • libbluedevil (Status: port available in a git branch, https://git.reviewboard.kde.org/r/108912/)
  • NetworkManager (Status: in progress)
  • pulseaudio (Status: in progress)
  • obex-data-server (Status: obsoleted and not ported to BlueZ 5)
  • gvfs-obexftp (Status: won't be ported)

How To Test

N/A (not a System Wide Change)

User Experience

N/A (not a System Wide Change)

Dependencies

N/A (not a System Wide Change)

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No

Documentation

N/A (not a System Wide Change)

Release Notes