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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
