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
