[pulseaudio-discuss] [PATCH 00/56] Refactor of BlueZ 5 support

[Tanu Kaskinen]

On Tue, 2013-07-16 at 13:04 -0300, João Paulo Rechi Vita wrote:
> On Tue, Jul 16, 2013 at 6:20 AM, Tanu Kaskinen
> <tanu.kaskinen at linux.intel.com> wrote:
> > Another thing (I should have brought this up earlier, but I only
> > realized this today): not having a generic module-bluetooth-discover
> > breaks old configuration files, which I hate (FWIW, I believe Arun
> > doesn't care about breaking configuration compatibility that much, I
> > don't know David's opinion). João, would it be too much to ask from you
> > to write a stub module-bluetooth-discover, which checks the bluez
> > version at runtime and then loads module-bluez4-discover or
> > module-bluez5-discover depending on the detected version?
> >
> 
> It was already agreed before that we would do it this way, and I don't
> think we should do a D-Bus roundtrip just to detect the BlueZ version.
> Right now we're compiling both modules by default and generating a
> default.pa that loads module-bluez4-discovery by default, so IMO it's
> already good enough to help packagers do the right thing. I'm not
> exactly sure what's the situation you want to improve not breaking
> configuration-file compatibility, but one way might make you happy is
> if we do not rename module-bluetooth-* to module-bluez4-* at this
> moment, and later when we decide to make BlueZ 5 support the default
> one we rename module-bluetooth-* to module-bluez4-* and
> module-bluez5-* to module-bluetooth-*. This will save us from breaking
> configuration files, but at the price of making the codebase a bit
> more confusing IMO, which I'm fine with as long as we have a good
> rationale for that.

The scenario that I'm talking about is when a user has modified
default.pa (either in /etc/pulse/default.pa or copied the file to
~/.config/pulse/default.pa). Package management tools may or may not
notify the user about the changes in /etc/pulse/default.pa, but they
will certainly not rewrite it automaticallly. So /etc/pulse/default.pa
may end up having the old contents. If the configuration is in the home
directory, the file will certainly not be updated.

I'm not sure why you're against doing a D-Bus round-trip. Is it for
performance reasons? Note that the round-trip is needed only if
PulseAudio is built with support for both BlueZ 4 and 5. Also,
distributions can, if they are concerned about the round-trip more than
about retaining configuration file compatibility, modify default.pa so
that it loads module-bluez*-discovery directly.

-- 
Tanu