On Mon, Nov 3, 2014 at 1:30 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote: > Felipe Sateler wrote on 03/11/14 12:55: >> 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. > > In this case, I'd recommend going with the lowest common denominator, > that is, using PA's own autospawn. > > Supporting multiple init systems is really hard and I'd suggest that > using different mechanisms all through the stack would make your test > matrix very large. Yes. But I'd rather give the better mechanism by default. While I'm all for supporting diversity, I don't think playing lower-common-denominator is the way to build a high quality distribution. > > With that in mind, if you're dealing with non-systemd setups at all, I'd > use the same mechanisms for both and at least cut down on the need for > testing different approaches there (and this rules out various things > when dealing with bug triaging etc). > >> 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. > > AFAIU, the --start patch was applied downstream already. Certainly it > was applied in Ubuntu and I checked with David regarding that one. I > didn't specifically check Debian however. No, we didn't disable that. > > As noted in the commit message there, the first call to pactl should > autospawn PA if autospawn is enabled and if not then the script will > fail. Either way, the net result should be the same provided you have > autospawn enabled (which was, and remains, the default when compiled > without systemd-daemon support). > > I think the only case where this is now different is if autospawn was > disabled, but you still wanted to use PA. The use case for that is very > corner case - typically it would be PA developers only (I used this > before for example, but now there are much easier semantics for stopping > and starting PA via the systemctl --user commands that can work at > runtime and save faffing around with config files etc. which is nice :)) > >> 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. > > 5. Build it with --disable-systemd-daemon and just use regular PA > autospawning as before. No need to worry about the missing "pulseaudio > --start" in the start-pulseaudio-x11 script as this was previously > patched out in Ubuntu and no-one seemed to mind there. That would be option 1, actually. > >> So, how could downstreams that need to support both systemd and >> sysvinit (selectable at runtime) do so? > > Hopefully I've answered your question, but feel free to discuss further > if you think there is still something that's not covered. Well, yes. But I did not want the answer to be: keep using autospawn ;). Because autospawn has its own class of problems (it can be autostarted by a service running as a different user, leaving the user without audio[1], or malformed configurations can thrash the computer[2]), I would really like to disable it by default. [1] In debian this problem was caused once by speech-dispatcher, which locked the audio device. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521675 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752762 -- Saludos, Felipe Sateler
