Hi all, Felipe Sateler wrote on 01/12/14 12:23: > On Mon, Dec 1, 2014 at 5:27 AM, David Henningsson > <david.henningsson at canonical.com> wrote: >> >> >> On 2014-11-29 22:04, Felipe Sateler wrote: >>> >>> Dbus integration with systemd user sessions is not complete yet. This >>> means >>> that a socket-activated pulseaudio daemon will not be able to access the >>> session >>> bus, and thus breaking several modules. >>> >>> This means that distributions should not yet enable the systemd units by >>> default >>> until that problem is solved. However, this does not mean that the units >>> cannot be >>> provided for the users that choose to experiment with them. >>> >>> Therefore, I propose to separate the decision to support socket activation >>> from the >>> decision to default to autospawn or not, via a separate configure switch >>> --enable-autospawn-default. This way one could build socket activation, >>> and not ship >>> it by default. >> >> >> One could still do that behaviour by just changing autospawn in >> /etc/pulse/client.conf, right? > > Almost. The problem is that if the user has a modified > ~/.config/pulse/client.conf, or (on debian-based distros at least) a > modified /etc/pulse/client.conf, they may not get the updated default. Indeed. This kind of thing will sadly always be a problem. >> It looks rather like we need to provide something that builds socket >> activation but disables it? And given the problems we have with socket >> activation (combined with session level D-Bus) maybe it makes sense to >> default to that? > > I'm not quite sure what you mean by "disabling it". AFAICT, the > current activation code does fall back to the normal socket opening > when no FD has been passed. So you can have a socket-activated server > running without socket activation. Yeah, the build itself is fine and continues to work. I'm not against splitting up the option here so that socket activation support gets build but not used and the old autospawn behaviour can be controlled - it's basically just a matter of not shipping the units (or shipping them but not running the "systemctl --global enable pulseaudio.socket" bit in the package scripts). I'd rather that the default value of PA_AUTOSPAWN_DEFAULT gets set depending on HAVE_SYSTEMD_DAEMON appropriately, but I'm not that fussed really. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
