With the following changes, the package builds just fine and we get rid of pulseaudio as dependency: -IUSE="+cups debug +udev packagekit policykit smartcard" +IUSE="+cups debug +udev packagekit policykit smartcard pulseaudio" if [[ ${PV} = 9999 ]]; then (...) - >=media-sound/pulseaudio-0.9.16 + pulseaudio? ( >=media-sound/pulseaudio-0.9.16 ) (...) $(use_enable smartcard smartcard-support) + $(use_enable pulseaudio pulse) $(use_enable udev gudev)"
Well, it may *build* fine, but a short looks at plugins/sound/gsd-sound-manager.c tells '-pulseaudio' would effectively be '-sound' - all of the code that actually does anything in the sound plugin is within '#if HAVE_PULSE..#endif' brace. media-keys would be crippled a bit too - VOLUME_UP_KEY, VOLUME_DOWN_KEY and MUTE_KEY need pulseaudio.
(In reply to comment #1) > Well, it may *build* fine, but a short looks at > plugins/sound/gsd-sound-manager.c tells '-pulseaudio' would effectively be > '-sound' - all of the code that actually does anything in the sound plugin is > within '#if HAVE_PULSE..#endif' brace. > media-keys would be crippled a bit too - VOLUME_UP_KEY, VOLUME_DOWN_KEY and > MUTE_KEY need pulseaudio. USE flags are used to control optional dependencies and settings. In this case pulseaudio is an dependency which can be made optional by the pulseaudio useflag. No user should be obliged to have pulseaudio installed even if that means not having a sound manager interface or whatever functionality it provides.
Sorry, but with GNOME 3 pulseaudio is a hard dependency. Although it shows up as a configure switch for gnome-settings-daemon, it's NOT optional for gnome-control-center and gnome-shell. Upstream is not interested in adding support for dmix, and neither am I. Maybe other gnome team members are interested. If you wish to do dmix port, take a look at gnome-shell.git/src/gvc/ and gnome-control-center.git/panels/sound/ . I am strongly against replacing support for pulseaudio with dmix, though, since it's officially a part of the gnome modulesets now, and is tightly integrated with the desktop. For instance, if you pickup a VoIP call via empathy, it'll pause your music player and movie player, and it'll soon do auto-echo-cancellation for your microphone for VoIP calls. It is also well-integrated into gnome-bluetooth for managing your bluetooth speakers and microphones out-of-the-box. Making *sound itself* optional for gnome-control-center and gnome-shell is out of the question, since it will remove all the GUI methods of volume control, leaving only alsamixer. Pulseaudio is NOT useless on devices without sound cards either, since it can transmit audio over the network, and can allow people to use sound on their machines. Besides, I don't think there are many machines out there with the ability to run GNOME Shell but not play sound. This dmix vs pulseaudio debate is reminiscent of the framebuffer vs Xorg debate a few decades ago. Guess who won. So, unless some GNOME team member has objections, I'm going to close this bug report as WONTFIX.
(In reply to comment #3) > So, unless some GNOME team member has objections, I'm going to close this bug > report as WONTFIX. If this can be reconsidered if, in the future, any other distribution makes the work for getting rid of pulseaudio hard depend (maybe debian :-/), I am ok with this resolution.
(In reply to comment #4) > (In reply to comment #3) > > So, unless some GNOME team member has objections, I'm going to close this bug > > report as WONTFIX. > > If this can be reconsidered if, in the future, any other distribution makes the > work for getting rid of pulseaudio hard depend (maybe debian :-/), I am ok with > this resolution. This is something we can look at if it happens. Do note that more and more GNOME applications are going to depend on PulseAudio, so trying to have alternate codepaths is just fighting the tide and adding maintenance overhead.
