On Fri, 2014-10-24 at 11:47 +0100, Colin Guthrie wrote: > David Henningsson wrote on 24/10/14 11:12: > > > > > > On 2014-10-24 11:42, Tanu Kaskinen wrote: > >> On Sat, 2014-10-18 at 20:43 +0200, Colin Guthrie wrote: > >>> 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. > >> > >> Would it make sense to disable all autospawn related code when > >> HAVE_SYSTEMD_DAEMON is defined? > > > > From a distro perspective, no. Just because systemd is a build > > dependency, does not mean that the end user wants to use systemd. > > > > Debian being the prime example of a distro supporting multiple init > > systems. > > Good point. > > With a maintainers hat on, I'd think it would be annoying to have to > support multiple ways of configuring things for the best out of the box > experience, so I may be tempted to just disable systemd socket > activation and just use the built in autospawn stuff everywhere (which > reduced my test matrix). But either way it shouldn't be too hard to > support both (only slight quirk would be the fact that a build has to > have one built-in default for whether autospawn is on or off, but > obviously the config files can change that as needed). Debian is indeed a good example why my idea was bad. I guess it would make sense to be able to disable autospawning with a separate configure switch, so that systemd-only systems would not have to worry about the autospawning code. I expect nobody will bother to add such switch, though. -- Tanu
