On Thu, Jul 28, 2016 at 10:04:41AM -0400, Felipe Sateler wrote: > On 28 July 2016 at 02:30, Josh Triplett <j...@joshtriplett.org> wrote: > > In the meantime, though: why split module-udev-detect into a separate > > module at all? The main pulseaudio package still depends on udev and > > libudev1, and several other components in the core package use it, so > > this doesn't reduce dependencies at all; it just introduces the > > possibility of breakage like this. > > It only depends on libudev, not on the udev daemon.
I misread https://packages.debian.org/sid/pulseaudio at a quick glance; it showed "dep: udev (>= 143) [powerpcspe, sh4, x32]", and I missed the architecture list at first glance. (Those architectures have an out of date version of pulseaudio.) > The story is as follows: > > 1. The default pulseaudio script loads module-udev-detect if it is available. > 2. If it fails to load the daemon start fails. > 3. The module fails to load if the udev daemon cannot be contacted. > 4. I want pulseaudio to be installable and usable inside containers > (contacting eg, remote sinks). > 5. udev does not start inside containers. > > Upstream maintains that 3 is correct behavior. So to support > containers without config changes by the user we need to either make > sure module-udev-detect can be unavailable, or ignore udev load > errors. The latter seems very undesirable, so that leaves us only > making it possible to not install module-udev-detect. This also has > the side benefit of not requiring a useless udev daemon inside the > container. I hope this makes clear why this was implemented. It does, yes. 1, 3, 4, and 5 seem reasonable; 2 seems like the problem. Why does ignoring module-udev-detect load errors (when the alternative is completely failing to start) seem undesirable? Ideally, pulseaudio should attempt to load module-udev-detect, and if that fails, load module-detect instead rather than giving up. - Josh Triplett
