[pulseaudio-discuss] [PATCH] module-gsettings: new module to store configuration using gsettings

[Felipe Sateler]

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:
>> > 2016-09-27 21:32 GMT+02:00 Felipe Sateler <fsateler at debian.org>:
>> > > I have to say I'm not sure how an upgrade scenario would play out. My
>> > > understanding currently is as follows:
>> > >
>> > > 1. paprefs can ship a file for gsettings-data-convert, which migrates
>> > > the settings.
>> > >
>> > > 2. However that tool is only run at login.
>> > >
>> > > 3. As a consequence, the paprefs tool can be in an inconsistent state
>> > > after an upgrade and before the next login.
>> > >
>> > > It seems that the problem is resolved by papfrefs triggering the tool
>> > > on startup as suggested by the gnome documentation[1].
>> > >
>> >
>> > 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.

>>
>> > > 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.
Restarting user (as opposed to system) daemons is a problem that is
not solved in general, and I don't expect to solve it now. It just
happens to be a fact of life that during some upgrades a logout-login
is required (especially on the complex desktop environments). If the
module is introduced before the updated papfref is shipped, the window
for such a glitchy upgrade lowers considerably.

[1] With my downstream maintainer hat on, package dependencies can be
tightened sufficiently so that this happens only once.

-- 

Saludos,
Felipe Sateler