[pulseaudio-discuss] Progress since PulseConf

[David Henningsson]

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