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

Reply via email to