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." 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. > > === 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. > === 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?). > > === 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. > === 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. > === "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 ? >> === Better drain/underrun reporting === >> >> * No work so far; and I can reiterate that it feels like it's quite >> far down on the priority list. Do you agree or should I try to start >> working on this (compared to other stuff)? > > I don't really have an opinion. I expect you to do what you want. But if > I had to choose between "low latency", "HDMI improvements" and "fixing > the drain bug" (I guess these were the things that you had some plans to > work on?), it would not be an easy choice. I'd probably pick "low > latency", but I'd assign pretty much the same priority to all three > tasks. Ok, I picked the drain bug because I figured it would be the least effort of the three...which is not to say it's easy :-) -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
