On Mon, 2013-03-04 at 11:47 +0100, David Henningsson wrote: > On 02/27/2013 06:44 PM, Tanu Kaskinen wrote: > > On Mon, 2013-02-25 at 09:42 +0100, David Henningsson wrote: > >> === Splitting of configuration === > >> > >> * I think we're currently waiting for Tanu to do some work on this > >> issue and come up with a more concrete proposal, is that correct? > > > > Yes, it probably is correct. I didn't know/think that people were really > > waiting for me, but now that I think about it, I probably did promise to > > do some work on this. I haven't yet done anything, but I'll try to focus > > on this "soon". > > > > As for proposals, here are some: > > > > === What to do first === > > > > There are two separate improvements for the configuration handling that > > were discussed: splitting the configuration into "core", "policy" and > > "hardware" bits, and moving all configuration under $(datadir) with > > support for overriding in $(sysconfdir) and $XDG_CONFIG_HOME. I propose > > that the configuration move is done first, because I feel that it would > > provide a more solid base for thinking about how the configuration split > > should be implemented. > > Hmm, reading the XDG spec, it says "Default configuration files should > be installed to $sysconfdir/xdg/subdir/filename with $sysconfdir > defaulting to /etc." Good point. I didn't read the spec before writing the proposals, so what I wrote was based on what I remembered from earlier readings. > Would it feel weird to put the default in /etc/xdg/pulseaudio/ , with > overrides in /etc/pulseaudio? I'm not an experienced admin, so I'm not > sure how other software does it. The way I read the spec, it looks like the expected behavior is not to have a separate directory such as /etc/pulseaudio. So, /etc/xdg/pulseaudio would contain the default configuration in the sense that those files are used in the absence of user configuration. The spec doesn't say anything about default configuration in the "upstream or distribution default" sense. How about this setup: * Use /etc/xdg/pulseaudio as the final fallback directory. The system administrator is expected to edit these files if system wide defaults need to be changed. * Support /etc/pulse as a legacy location only. Files here override the files in /etc/xdg/pulseaudio. * Install the original default configuration in /usr/share/pulseaudio/config for reference only. These files wouldn't be used by pulseaudio. > > === Including system configuration files from user configuration === > > > > If /etc/pulse is only used for overriding the upstream defaults, a > > situation may arise where a user has ~/.config/pulse/default.pa, and he > > would like to include the system version of the file, > > but /etc/pulse/default.pa doesn't exist. In that > > case, /usr/share/pulseaudio/config/default.pa should be included, but > > how does the user express that in the configuration file? A couple of > > options: > > > > .ifexists /etc/pulse/default.pa > > .include /etc/pulse/default.pa > > .else > > .include /usr/share/pulseaudio/config/default.pa > > .endif > > > > .include[search_start_level=system] default.pa > > > > The "search_start_level" option would accept values > > "base" (/usr/share/pulseaudio/config), "system" (/etc/pulse), > > "user" (~/.config/pulse) or > > "user-machine" (~/.config/pulse/machine-id-<machine-id>). The default > > would be "user-machine". > > > > The first option is annoyingly verbose, but it's easy to understand and > > supported today. I would really like this to be possible with one line, > > like in the second example, but I think it's more important that it's > > obvious what the include command does. I don't think it's obvious what > > "search_start_level=system" means, and I can't think of any better > > syntax, so if better proposals don't appear, I prefer the clear but > > verbose option. > > We could also add something like a: > > .include-fallback > > or > > .include-default > > where this "include-fallback" or "include-default" would take the > current file's "override level" and continue from there. I don't actually like the current situation where the default configuration needs to be explicitly included. I think the most intuitive setup is to always read both the system configuration and the user configuration, so that the user configuration overrides whatever was set in the system configuration. This doesn't work for scripts such as default.pa, so there explicit including will be needed, but I propose that the "ini style" files that we have are processed as I described. I quite like your ".include-default" suggestion. I propose that we implement it for script files. > > === Including relative paths === > > > > Currently, ".include somefile.conf" treats somefile.conf as a path > > relative to the directory of the current file. I propose that it's > > changed so that ".include somefile.conf" does a full search: first in > > the user configuration directory, then in the system directory, and so > > on. The reason is that if the system configuration is split into several > > files, without this change only the "root" file could be overridden by > > the user, because the non-root files would never be searched in the user > > directory (we could implement some extra syntax so that the system > > configuration could use ".ifexists $USER_CONF_DIR/somefile.conf", but I > > don't think that's a better solution than doing a full search for > > relative paths). > > ...hmm, given this example, we could instead just extend ".include" to > never be recursive, i e skip files that are already included. Thus, > writing ".include default.pa" inside default.pa would be perfectly valid > (but look a bit confusing perhaps?). Yes, I think that would be confusing. > > === Machine specific user configuration === > > > > Configuration files should be searched in > > ~/.config/pulse/machine-id-<machine-id>/ too. The reason is that the > > configuration can be machine specific. I don't remember that anyone > > would ever have requested this feature, but this seems like the right > > thing to do, and adding another directory to the list of search paths > > should be trivial. > > And another file to add to the list of things to check when things go > wrong, perhaps. A valid concern. I withdraw this proposal. We can come back to it when someone actually needs per-machine user configuration. I guess it would be nice to track the origin of every bit of configuration in the daemon, and make that information available through an API. pactl show-configuration could then print the full configuration of the running daemon, along with the origin information. There could also be an offline variant, which wouldn't connect to a daemon, but would inspect the configuration files directly instead. > > === Moving state files to $XDG_DATA_HOME === > > > > I think a "configuration file" means a file that is meant to be directly > > edited by the user. The various module-foo-restore database files are > > not configuration files, so they should be moved under $XDG_DATA_HOME. > > I don't have a strong opinion on this one, not sure if it's worth the > effort. I'm also having second thoughts, so I withdraw my proposal. It would actually be nice if the database files were stored as text and formatted as configuration files. Inspecting and tweaking the databases would then be easier. There are a couple of problems with that, though: * The files would be automatically generated, so the user would have limited control over the formatting (e.g. comments would be useless, because they would be lost the next time PulseAudio rewrites the file). * Changes made to the files while PulseAudio is running would likely get lost due to PulseAudio overwriting the files, unless PulseAudio monitored the files for changes. If it was just the restore databases, the above problems would probably be enough to forget about the whole thing, but the same problems actually affect "normal" configuration too: there are some options in daemon.conf which I think would be good to have modifiable at runtime, such as the flat-volumes option. If there would be an API for setting the flat-volumes option, that option would have to be saved somewhere, presumably in daemon.conf, which would trigger the problems mentioned above. I can see modules wanting to maintain their configuration in a similar way: have the options modifiable at runtime through an API, but also allow editing the options with a text editor. I don't plan to work on this any time soon, but I'd like comments about this anyway. > > === "pulse" vs. "pulseaudio" === > > > > There's an annoying inconsistency in the directories that pulseaudio > > uses: "pulse" vs. "pulseaudio". There's /usr/share/pulseaudio, but > > otherwise we use "pulse" in paths. I would prefer to use "pulseaudio" > > everywhere, but I don't think changing the current scheme is worth the > > effort. I brought this up, however, because if others think that yes, > > this change makes sense and is worth the effort, I could work on this > > too while files are moved around anyway. > > I prefer pulseaudio over pulse too. I guess that at least every "new" > subdirectory that is created due to this move should be "pulseaudio" > rather than "pulse"? > > Also the .config/pulse dir is quite new, perhaps we can just change it > to .config/pulseaudio ? I proposed above that /etc/pulse would be deprecated in favour of /etc/xdg/pulseaudio, so I propose that we go all the way and deprecate .config/pulse too and use .config/pulseaudio. -- Tanu
