Hi, I'm replying to this message but I the general question is a bit broader than just this default. On Mon, Nov 3, 2014 at 6:42 AM, Colin Guthrie <colin at mageia.org> wrote: > When enabled, this method is prefered over pulseaudio's built in > systems so we should try our best to ensure that it cannot be spawned > outside of the mechanisms desired. > > Packagers should call 'systemctl --global enable pulseaudio.socket' to > enable the socket for all users, or alternatively ship an enabling > symlink in /usr/lib/systemd/user/sockets.target.wants/ folder. It may > also make sense for distributions to add in a ConditionNNN= line to the > socket unit if they have a downstream mechanism for enabling or > disabling pulseaudio. > > If individual users wish to opt out of this vendor (or administrator) > decision, they can call 'systemctl --user mask pulseaudio.socket' Some of the vendors (like debian) need to support both systemd and non-systemd usage, which needs to be detected at runtime. This patch makes the default configured at build time, which is undesirable. Moreover, in combination with the --start patch it leaves non-systemd users with no pulseaudio started at login. So, how could we accomodate non-systemd users when this patch set enabled? I see the following options: 1. Do not enable the systemd user units (we might need this anyway until dbus properly supports a login bus in debian, but for the purposes of this discussion lets assume this problem has been solved). 2. Revert the --start patch so that non-systemd users get pa started on login. Or maybe guard the --start with a check for /run/systemd. 3. Revert this patch. 4. Do not accomodate non-systemd users. 4 is clearly undesirable. 1 would be a shame since systemd service management is nice. I'm not sure how to evaluate 2 and 3. My gut tells me 2 is better, but I don't know if either could cause problems. So, how could downstreams that need to support both systemd and sysvinit (selectable at runtime) do so? -- Saludos, Felipe Sateler
