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

[Luiz Augusto von Dentz]

Hi Joao,

On Wed, Jul 17, 2013 at 12:44 PM, Tanu Kaskinen <tanu.kaskinen at intel.com> wrote:
> 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.

Btw, the check for bluez.pc file is probably bogus, we should install
bluez.pc file even if we are not installing any library to provide the
exact version is on the system, so we probably need to fix this in
BlueZ 5.8, but because we didn't bother with the pc file so far
perhaps we should default to 5 in case of missing pc file anyway.
Perhaps we can do as Tanu suggest during runtime and leave
module-bluetooth-discover there which would just figure out which
version of BlueZ is running during runtime a load the right module for
it e.g. module-bluez4-discovery or module-bluez5-discovery.


--
Luiz Augusto von Dentz