On 28 July 2016 at 02:30, Josh Triplett <j...@joshtriplett.org> wrote: > On Fri, 22 Jul 2016 09:49:19 -0400 Felipe Sateler <fsate...@debian.org> wrote: >> On 21 July 2016 at 21:43, Sean Laguna <sean.lag...@gmail.com> wrote: >> > On Fri, 15 Jul 2016 10:08:52 -0400 Felipe Sateler <fsate...@debian.org> >> > wrote: >> >> On 15 July 2016 at 03:51, Francois Mescam <franc...@mescam.org> wrote: >> >> > Thanks after installing pulseaudio-module-udev the message disappear. >> >> > >> >> > I have not disbled installation of Recommends but I install them >> >> > manually >> >> > and I think I've miss to install this package. >> >> > >> >> > You can close the bug. >> >> >> >> OK, doing so. >> >> >> >> -- >> >> >> >> Saludos, >> >> Felipe Sateler >> > >> > I think a problem here is that Debian recently removed this module from the >> > base pulseaudio package: >> > http://lists.alioth.debian.org/pipermail/pkg-pulseaudio-devel/2016-April/006197.html. >> > Like the OP, I had to manually install it to get my default behavior back. >> >> Did you configure apt to not install Recommends by default? > > I ran into this same problem on upgrade, and yes, I have apt configured > to not install Recommends. The default Recommends of core packages > install far too much; over time, that has been fixed somewhat, and I do > look forward to re-enabling it someday. I've filed various bugs on > packages with excessive Recommends, as have many other people, and I've > seen several threads on debian-devel about what the default installation > installs.
Recommends exist for a reason. Moving a Recommends to a Depends takes freedom away from users. Why do people who disable installation of Recommends insist that this freedom be removed (for other users)? From where I stand, the burden of is on their side for ignoring the distribution recommendations. > 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. 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. > Would you consider either merging module-udev-detect back into > pulseaudio, or making it a Depends? I'm still thinking about it. To be honest, I don't particularly like making inferior packages to accomodate a non-default setting that should only be used with care (after all, Recommends is defined as stuff that almost always should be installed together). On the other hand, I don't want to deal with endless bug reports either. So I'm still undecided... -- Saludos, Felipe Sateler
