[pulseaudio-discuss] Progress since PulseConf

[Tanu Kaskinen]

On Thu, 2013-03-07 at 08:22 +0100, David Henningsson wrote:
> On 03/06/2013 05:47 PM, Tanu Kaskinen wrote:
> > On Mon, 2013-03-04 at 11:47 +0100, David Henningsson wrote:
> >> 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.

I'm OK with that.

> >> 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.

Great!

> > 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 :-)

It doesn't sound particularly hard to me. I suggest to make it one of
the potential GSoC projects.

> >>> === 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?

Do you mean that we should move the alsa-mixer files to the
configuration directory? If so, I don't agree. The files shouldn't
contain any user preferences. If the user needs to change those files,
it means that the data is wrong or incomplete, in which case we should
fix it upstream. Or it might be that we don't provide enough
configuration knobs: you pointed out in IRC that there has been a
request for turning off jack detection for a specific port without root
access. If this is indeed something that users should be able to
configure, it should be done elsewhere than in the alsa-mixer files.

(FWIW, I previously did want to move the alsa-mixer files in the
configuration directory, but I changed my mind just a moment ago after
chatting with Arun in IRC.)

> >> 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?

Good point. Having /etc/pulse as a supported legacy location would work
for the ini-style files, but it wouldn't work for default.pa, because
the old version would always be used. We could provide a migration
script that would remove /etc/pulse/default.pa, but then modifications
done by the administrator would be lost. I think it's a pretty standard
feature in distributions to handle upstream default configuration
changes in a more or less graceful manner, but I doubt that the
distributions are able to handle moving configuration files without
custom scripting.

This seems like a hassle that is not worth the effort, so I propose that
we keep /etc/pulse as the canonical system configuration directory.
There's then the question whether ~/.config/pulse should be renamed to
~/.config/pulseaudio or not. I'm fine with either alternative, but I
slightly prefer the option of not doing anything.

-- 
Tanu