Bug#831355: pulseaudio: Use module-udev-detect instead of module-detect

Felipe Sateler fsateler at debian.org
Fri Jul 29 14:51:09 UTC 2016


On 28 July 2016 at 16:33, Josh Triplett <josh at joshtriplett.org> wrote:
> On Thu, Jul 28, 2016 at 10:04:41AM -0400, Felipe Sateler wrote:
>> 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.

Unfortunately the pulseaudio loader scripts are not very expressive so
I don't think that is possible to achieve.

I discussed this with upstream:

<fsateler> tanuk: do you recall/know why does the default.pa loads
module-udev under a .fail section?
<fsateler> context is, people were complaining due to the module-udev
split into a separate package
<tanuk> fsateler: I don't remember, but I would guess that there's no
reason for module-udev-detect to fail if it's present.
<tanuk> fsateler: How is the package split related?
<tanuk> module-udev-detect is guarded by .ifexists module-udev-detect.so
<tanuk> So there should be no failure if the module isn't installed.
<tanuk> fsateler: Hmm, maybe you were considering to remove that
.ifexists check, and you'd like module-udev-detect to fail gracefully
if udev isn't present/usable.
<tanuk> fsateler: IIRC, this was discussed earlier (with you?), and my
take-away was that while it has some drawbacks, it would be best if
module-udev-detect would fail gracefully when it can't connect to
udev.
<tanuk> Nobody has submitted a patch, however.
<fsateler> (sorry, got kidnapped into a meeting)
<fsateler> tanuk: it is related because a user was asking why not
simply ship the udev module, and have it fail if udev is not available
<fsateler> or in other words, a reason for the split is that the
daemon fails to start if the module fails to load
<fsateler> so a user asked why would the daemon fail to start. and I
didn't have an answer to that ;)
<fsateler> tanuk: is it possible for a module to exit gracefully with
"nothing to do" ?
<tanuk> fsateler: Yes.
<tanuk> Well, there's no special return code for "nothing to do".
<tanuk> We have module-combine, which is deprecated and just loads
module-combine-sink and then does nothing (module-combine still stays
loaded).
<tanuk> And module-hal-detect-compat loads module-udev-detect, and
also requests itself to be unloaded after that.
<fsateler> ok
<fsateler> so I guess the way forward would be to make a patch for
module-udev-detect to just:  if (!connect_to_udev()) { return 0; }
<fsateler> or something similar in spirit
<tanuk> Yes. And include a comment why it's desirable to support
systems that want to have module-udev-detect installed when udev isn't
available.
<fsateler> ok
<fsateler> tanuk: do you mind if I copy paste this conversation into
the bug log?
<tanuk> Feel free.


So the way forward would be to patch module-udev-detect to exit
gracefully if udev is not present. One could even chain load
module-detect if udev is not available.

I guess patches welcome :).

-- 

Saludos,
Felipe Sateler



More information about the pkg-pulseaudio-devel mailing list