On Tue, 2018-04-17 at 14:23 -0300, Felipe Sateler wrote: > On Tue, Apr 17, 2018 at 3:07 AM, Tanu Kaskinen <tanuk at iki.fi> wrote: > > Originally the idea was to provide the "modules" schema with paprefs, > > but since module-gsettings refers to the "modules" schema in its code, > > that would make module-gsettings depend on paprefs, which is not good. > > Now all schemas are provided by module-gsettings, so the paprefs > > dependency is avoided. Unfortunately this means that if paprefs is > > modified to load some new modules, the schema in pulseaudio needs to be > > updated as well. > > I have two questions: > > 1. Wouldn't it be better to do the schema migration in pulseaudio > then? I find it weird that the client is responsible for doing the > migration instead if pulseaudio, if it is pulseaudio that ships the > schema. Yes, that's a bit weird. Running gsettings-data-convert from module- gsettings should work fine. I'll submit a patch for doing that. The two gsettings-data-convert related patches for paprefs can probably be simply dropped. > 2. If the answer to (1) is "yes", maybe it would be best to have > gsettings supersede gconf? Ie, offer the gconf module only when > gsettings will not be built. > > I can't think of a usecase for having both enabled at the same time... I already submitted a patch that enables only gconf or gsettings if both are available. If a distribution really wants to enable both, that's possible, but in that case it should ensure that at runtime module-gconf and module-gsettings aren't installed at the same time. One reason to build pulseaudio with both modules would be to allow updating pulseaudio before paprefs. An old paprefs version would then keep working with a new pulseaudio version, and when paprefs is updated, pulseaudio won't need to be rebuilt with different options. I don't know if there will be need for that in practice, though. -- Tanu https://liberapay.com/tanuk https://www.patreon.com/tanuk
