On Wed, 2016-10-05 at 12:14 -0300, Felipe Sateler wrote: > On 5 October 2016 at 05:17, Sylvain Baubeau <lebauce at gmail.com> wrote: > > > > > > > > 2016-10-04 13:04 GMT+02:00 Tanu Kaskinen <tanuk at iki.fi>: > > > > > > > > > On Fri, 2016-09-30 at 23:21 +0200, Sylvain Baubeau wrote: > > > > Thanks for pointing this out. I updated my paprefs patch to apply > > > > paprefs.convert at startup. > > > > > > Would it be feasible for you to make it a build time option to use > > > gconf or gsettings in paprefs? > > > > > > Yes, I think it's feasible but the code would need quite a lot of rework. > > I don't think this is necessary. If it's not configurable, that will force the gsettings transition on all distros. But I think I agree that it's good enough if the data gets moved on the first run of the new paprefs version, even if paprefs won't necessarily work before pulseaudio gets restarted. > > > > > However that leaves us with another problem, as the pulseaudio daemon > > > > > is not restarted automatically after an upgrade, and thus gsettings > > > > > module might not be loaded. But, I hope paprefs can already deal with > > > > > such a scenario and prompt the user accordingly. > > > > > > > > > > > > > Unfortunately, paprefs does not deal with such a scenario. It will > > > > therefore be able to modify the configuration but this configuration > > > > will > > > > only take effect when pulseaudio is restarted. What do you suggest > > > > prompting the user with ? > > > > > > Figuring out a good message is tricky. paprefs could just say "module- > > > gsettings not loaded", but it would be nice to able to tell the user > > > what to do. However, module-gsettings not being loaded may be because > > > the server is too old version and doesn't support module-gsettings at > > > all (distributions can deal this by depending on new enough server, > > > though), or it has been removed from default.pa and needs to be added > > > there, or the server has been updated but not restarted. The last > > > reason is the most likely one in the beginning, but over time it > > > becomes less and less likely, so just saying "restart pulseaudio" or > > > "reboot the machine" probably isn't a good idea. > > > > > > > > > > > > > > > > > In debian there is only paprefs depending on module-gconf. I don't > > > > > think we'll keep module-gconf after paprefs has migrated. > > > > > > If we release a pulseaudio version with module-gsettings before we > > > release paprefs with gsettings support, will you run pulseaudio with > > > both gconf and gsettings enabled, or only with gconf? Running with both > > > would have the benefit that if everything goes well, the data will be > > > migrated without any glitch when the new paprefs version is run for the > > > first time, because module-gsettings will be already loaded. The risk > > > with that is that the migration can't be tested at the time you enable > > > module-gsettings, since paprefs isn't ready. If there's some unforeseen > > > problem when paprefs is finally updated, and module-gsettings needs to > > > be fixed in some way, the migration might become even more complex, > > > because you need to deal with detecting a situation where the server is > > > running with a broken version of module-gsettings. > > > > > > > You're right, it's probably too complicated. It's better to stick with > > GConf. > > FWIW, I'd rather face a one-time upgrade glitch[1] than be stuck > forever with an unmaintained stack. So I don't agree that it is better > to stick with GConf. > > From my POV, making paprefs do the migration automatically is all that > is missing to perform an upgrade that is as seamless as possible. (I'm not sure my nitpicking is productive, but here it goes anyway:) It's not as seamless as possible, because there's a chance that paprefs won't work before pulseaudio gets updated. Also, the data move itself can cause glitching, because the modules loaded by module-gconf will be unloaded and then reloaded by module-gsettings. Maybe you're arguing that it's not possible to get rid of these glitches, but I think it is possible. Whether it makes sense to spend time implementing a "perfect" solution is a different question, however. --Â Tanu
