On 6 October 2016 at 08:28, Tanu Kaskinen <tanuk at iki.fi> wrote: > 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. Distros can do the transition on their own pace by delaying the paprefs update. Paprefs is AFAICS a mature piece of software, it is not getting new releases frequently anyway. Delaying a couple of months the release would not be terrible I think. > >> > > > > 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. Right, my use of "as possible" was not very clear. Sorry for the confusion. I should have added "at reasonable effort". I'll expand a bit below > 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. I do not know if it is possible, or how much effort it takes. I do place a relatively low cost on one-time upgrade glitches that are solved after a login/logout cycle. Therefore, I think that it does not make much sense to spend too much effort in making this upgrade even better. This is how I envision the upgrade scenario for a distro like debian: 1. Introduce the new pulseaudio with module-gsettings enabled in parallel to module-gconf. Make it 2. Do not introduce the new paprefs for some time. A couple of months should be sufficient. 3. Introduce the new paprefs. Ensure sufficiently strict dependencies with a pulseaudio daemon that supports gsettings. 4. At some later version, drop the gconf module. Add a Breaks relationship to older paprefs that do not support gsettings. The time window in 2 is to make as few people as possible not face the problem of having a running pulseadio daemon that does not support module-gsettings.[1] Note that the alternative to this less-than-perfect upgrade process is not glitchless status quo. It is my understanding[2] that gconf will eventually be forcefully removed from mainstream distros when sufficiently few apps use it, so the alternative is really to drop paprefs and module-gconf entirely in a (possibly far) future date. [1] In fact, we are getting close to a release in Debian. Maybe I could even wait until stretch is released before updating paprefs (AFAIK, gconf will still be part of debian in stretch), and update shortly after it. [2] Based on how distros normally work, I don't have any specific plans to quote. But maintainers of obsolete software usually don't want to keep maintaining it forever. -- Saludos, Felipe Sateler
