On Tue, Nov 4, 2014 at 3:39 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote: > Felipe Sateler wrote on 03/11/14 20:28: >> 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. > > Cool, well, in that case there are still options (see below). > >>> 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. > > Well, I *think* it'll work OK assuming you also (typically) left > autospawn on. The fact it was disabled on Ubuntu gives some degree of > confidence that it should be fine generally for everyone :D > > So I don't think this line would need to change if you switched from > PA-autospawn to systemd socket-activation - both should ultimately start > a daemon (hopefully as the right user in the case of the former ;)) > >>>> 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. > > Yeah, I have fought with it before. It's actually been quite a useful > and highly visible indicator of wider environment leakage (e.g. leaving > XDG_* set after su or sudo or pkexec) which means it got fixed. Without > PA's autospawn getting all in your face, some of the other issues likely > would have gone unnoticed! > > That said, I'm pretty sick of them now myself too, so yes socket > activation will be much nicer :D > > So, back to the point, the only thing that really differs between the > builds when systemd support is built is the default value of autospawn > for the client, so all you really need to deal with downstream is > setting up /etc/pulse/client.conf correctly. > > If you wanted to go really far, you could also hack PA source to check > for systemd as an init (just checking sd_booted() I guess) and make the > default based on that - while it's not the same as using the user > daemon, it's 99% accurate IMO. It would make the default value shown in > the config file (but commented out) sometimes wrong, but that's mostly > cosmetic. > > We could technically just do this upstream. I don't think I'd be against > such a change if no-one else complains. I had thought of that. I think this is a reasonable compromise: business as usual for the no-systemd crowd, and improved support for the rest. I will try to cook something up along the lines of your suggestion (I don't think you can assign a method call result to a const struct field...). I'll let you know if I have something that works. -- Saludos, Felipe Sateler
