On 03/06/2013 05:47 PM, Tanu Kaskinen wrote: > 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. The question is if we need such a directory. I can see the use for it, but it is a tradeoff between easier to do customisations and less places to look in when things go wrong. > 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. I would prefer to skip the "reference only" files. It is both confusing and unnecessary bloat to install files that aren't actually used. >>> === 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. That looks okay to me too. >>> === 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. Sounds ambitious :-) >>> === 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. Thinking more about this, we actually have a third type of human-changeable configuration; 1) ini-style client/daemon.conf 2) script-style default/system.pa 3) ini-style ALSA path and profiles. The first two are considered configuration (as in, they are under /etc ), whereas the third is considered data ( /usr/share ). The third isn't user overridable. I'm not holding you accountable for this design of course, just wondering if we should reconsider what's configuration and what's data here? > 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. Do you think we should do anything on upgrade migration, i e moving files or adding symlinks? -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
