[pulseaudio-discuss] [PATCH] module-gsettings: new module to store configuration using gsettings
fsateler at debian.org
Thu Oct 6 13:18:17 UTC 2016
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 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
> 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,
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
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
Note that the alternative to this less-than-perfect upgrade process is
not glitchless status quo. It is my understanding 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.
 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.
 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.
More information about the pulseaudio-discuss