Since skype-4.3.0.37, there is a reason to install pulseaudio[alsa] even if one does not plan to "switch" to pulseaudio, that is, even if one has USE="alsa -pulseaudio" for other applications. In this setting, media-plugins/alsa-plugins (especially with the pulseaudio USE-flag) is not only unneeded, it is even contraproductive if the users do not remove (or edit) /usr/share/alsa/alsa.conf.d/51-pulseaudio-probe.conf Note that this file is not meant to be edited (it is not even CONFIG_PROTECT'ed by default). Therefore, I suggest to make the PDEPEND on media-plugins/alsa-plugins[pulseaudio] optional. One could make a USE-flag for this PDEPEND, but according to current gentoo policy, USE-flags which do not change the installed program are undesired. Thus, I suppose that instead of the dependency one should add something like use alsa && \ optfeature "alsa using pulseaudio" "media-plugins/alsa-plugins[pulseaudio]" to pkg_postinst() (eutils required for optfeature is already inherited) to inform the user that he might want to install the dependency if he did not yet.
Sounds good.
Reading skype ebuild looks like it won't pull pulseaudio if you disable "pulseaudio" USE flag (even if it's default enabled by ebuild because looks like it needs pulseaudio for sound), then, I don't see the issue :/
(In reply to Pacho Ramos from comment #2) > Reading skype ebuild looks like it won't pull pulseaudio if you disable > "pulseaudio" USE flag (even if it's default enabled by ebuild because looks > like it needs pulseaudio for sound), then, I don't see the issue :/ So you think what Martin said in the original report is not a problem, because it's possible to install Skype, a program used for voice calls, without support for sound? Even regardless of Skype, there is no reason for the pulseaudio ebuild to force alsa-plugins to install with pulseaudio support. Can someone please fix this so we don't have to carry this change in local overlays?
(In reply to Mikael Magnusson from comment #3) > So you think what Martin said in the original report is not a problem I am afraid that this sounds agressive. If Pacho has only looked at the skype ebuild, he could not see what is going on. So let me explain in more detail: It is possible to install skype without pulseaudio, and then skype can still be used for text messages. However, if one wants to use skype for VOIP (which is probably the reason for most people to install skype), it is necessary to install pulseaudio: skype is not able to use alsa or anything else as a replacement for sound output. This behaviour has changed in the newest skype version and is not visible from the ebuild. Maybe there are also other programs which provide audio output only with pulseaudio, but currently skype is the only example I am aware of. However, I think skype is popular enough to care about. For these programs it is necessary to have pulseaudio installed, even if for some reason one does not want to use pulseaudio as a sound server for other programs. This is currently only possible if one patches the pulseaudio ebuild.
(In reply to Martin Väth from comment #4) [...] > For these programs it is necessary to have pulseaudio installed, even if for > some reason one does not want to use pulseaudio as a sound server for other > programs. > This is currently only possible if one patches the pulseaudio ebuild. Then, you want something like having pulseaudio enabled only while running skype? Well, the problem if not installing the plugins by default when people enable widely pulseaudio USE flag (that is usually to run pulseaudio) is that pulseaudio will only work for apps using directly pulseaudio and apps using alsa won't work at all :/ (I think that is the reason we added it so many years ago) I would prefer to keep thinking on a better solution :|
Also, if I don't misremember, sound was routed to pulseaudio due alsa-plugins[pulseaudio] only if pulseaudio was running, if you are not running it, is it still routed to it?
(In reply to Pacho Ramos from comment #5) > Then, you want something like having pulseaudio enabled only while running > skype? Yes, exactly. > apps using alsa won't work at all If it is that severe, it might perhaps justify to introduce a USE-flag even if it does not influence the installed binary: After all, USE-flags are there to enable choice. How about USE=minimal? People enabling USE=minimal will not expect the full functionality of the package. Additionally, a warning might be printed if that USE-flag is enabled. However, people wanting only a "minimal" pulseaudio installed can still have it. (In reply to Pacho Ramos from comment #6) > if you are not running it, is it still routed to it? Yes, if pulseaudio is configured: I just installed alsa-plugins[pulseaudio] on a freshly booted system and started mplayer (compiled with USE=-pulseaudio), and immediately pulseaudio is started and used. When I remove /etc/pulse/defaults.pa this does not happen, but then skype won't work, either.
(In reply to Martin Väth from comment #7) [...] > When I remove /etc/pulse/defaults.pa this does not happen, but then skype > won't work, either. I think what you should try is to configure ALSA to not use pulse as output then, that way apps using ALSA directly will keep using it while apps using directly pulseaudio should be kept away. Anyway, that will cause some apps to not be eared (depending on whether you are running pulseaudio or not) and (the thing I hate most), one app blocking the others from using sound. That is the main reason an doubt about letting people to play with this depending on set USE flags What I would do to allow your setup (that is a bit "special" as you will have a mix that will also cause other problems as I commented) is to try to configure your alsa setup to not use pulse by default. The problem is that I don't remember how to do that on Gentoo :/ I think you could try to configure the output you want for your system using /etc/asoundrc as explained at: http://www.alsa-project.org/main/index.php/Asoundrc#The_default_plugin
Created attachment 384474 [details, diff] patch to make alsa-plugins[pulseaudio] depend on alsapulse USE-flag
(In reply to Pacho Ramos from comment #8) > I think what you should try is to configure ALSA to not use pulse as output > then Exactly. And the natural way to do this is to not install ALSA plugin which outputs to pulseaudio, i.e. to *not* install media-plugins/alsa-plugins[pulseaudio] That's what this bug is about. > Anyway, that will cause some apps to not be eared > (depending on whether you are running pulseaudio or not) All apps I tested (outputting to alsa) will be heared. Apps outputting to pulseaudio: skype is heard. I have not tested apps with the pulseaudio USE-flag. According to your claim they are not always heard, although I do not see the reason (if they are outputting to pulseaudio, they should not need the alsa plugin). Anyway, if you are right, this app might get RDEPEND="pulseaudio ? media-sound/pulseaudio[-minimal]" > one app blocking the others from using sound. This does not happen. Maybe it did happen with OSS3 ages ago, but alsa has no problem if several applications use it. > letting people to play with this Letting people decide what they want is the Gentoo way. > is to try to configure your alsa setup to not use pulse by default. Force installation of a plugin and then hack around that this plugin is not used? This would be pure nonsense.
Looks like QA team has decided to directly overwrite us without even commenting here. I strongly disagree with that procedure but, ok, I will keep it as-is but, please, next time at least ping us or similar: *pulseaudio-5.0-r6 (04 Dec 2014) 04 Dec 2014; Michał Górny <mgorny@gentoo.org> +pulseaudio-5.0-r6.ebuild: QA: Replace unnecessary, blocker-causing alsa-plugins[pulseaudio] dependency with a safe postinst message.
Well, there is a problem now: How do we prevent people from breaking their setups on next "--depclean" run when alsa-plugins is likely to be removed from their systems without any message at all? :| Maybe a pkg_prerm message for alsa-plugins when pulseaudio[alsa] is present? (and rely on people reading the messages AFTER depcleaning?)
We have being talked with other team members and we agreed on: # Pacho Ramos <pacho@gentoo.org> (05 Dec 2014) # QA team didn't even talk to us and bypassed bug #519530 # Hardmasking until this is discussed futher as we have agreed # in the team =media-sound/pulseaudio-5.0-r6
pulseaudio alsa plugin must get on systems using pulseaudio by default. This is called actual full QA, as opposed to packaging level QA. However the latter is handled, is another matter, and we can work on that, given the prime requirement of having stuff work out of the box is kept in mind.
We have discussed in #gentoo-qa that it can be a problem because USE=alsa controls also ALSA support in general as the original issue based on topic seems to be about, but kinda diverted a lot. Disabling USE=alsa would also mean no support for PA to work at all, unless OSS is used instead, as then the alsa sinks and source modules aren't built, default configuration lacks some stuff and some alsa isn't tested for at all at runtime for which sound system to use, so unless it's solaris, win32 or some oddball OSS3 system, it doesn't work at all. The plugin is also unnecessary on systems where it is known that all sound output is PA native, not ALSA API. While purely dependency controlling USE flags violate some sort of QA policy, the benefits should outweight that, until we have proper runtime only USE controlled dependency support in some far future EAPI. As such I have OKed the following dependency instead: PDEPEND="alsa? ( alsa-plugin? ( >=media-plugins/alsa-plugins-1.0.27-r1[pulseaudio] ) )" with +alsa-plugin in IUSE (default enabled)
I've updated the ebuild and removed the mask. Hope everyone's going to be happy now.
(In reply to Mart Raudsepp from comment #15) > As such I have OKed the following dependency instead: > > PDEPEND="alsa? ( alsa-plugin? ( > >=media-plugins/alsa-plugins-1.0.27-r1[pulseaudio] ) )" > > with +alsa-plugin in IUSE (default enabled) (In reply to Michał Górny from comment #16) > I've updated the ebuild and removed the mask. For the record (and with my QA hat on): I also approve of this.
(In reply to Ulrich Müller from comment #17) > (In reply to Mart Raudsepp from comment #15) > > As such I have OKed the following dependency instead: > > > > PDEPEND="alsa? ( alsa-plugin? ( > > >=media-plugins/alsa-plugins-1.0.27-r1[pulseaudio] ) )" > > > > with +alsa-plugin in IUSE (default enabled) > > (In reply to Michał Górny from comment #16) > > I've updated the ebuild and removed the mask. > > For the record (and with my QA hat on): I also approve of this. why obligatory?
(In reply to Perfect Gentleman from comment #18) > why obligatory? It wouldn't be under normal circumstances, but read today's thread on the topic in gentoo-dev.
(In reply to Pacho Ramos from comment #11) > Looks like QA team has decided to directly overwrite us without even > commenting here. I strongly disagree with that procedure but, ok, I will > keep it as-is but, please, next time at least ping us or similar: Maybe because you ignored a severe bug for 3 months. (In reply to Michał Górny from comment #16) > I've updated the ebuild and removed the mask. Hope everyone's going to be > happy now. Thanks for finally applying my patch :).
(In reply to Mart Raudsepp from comment #15) > PDEPEND="alsa? ( alsa-plugin? ( > >=media-plugins/alsa-plugins-1.0.27-r1[pulseaudio] ) )" The alsa? ( ) conditional was still missing in the change that was applied. Fixed now.
(In reply to Mikael Magnusson from comment #20) > (In reply to Pacho Ramos from comment #11) > > Looks like QA team has decided to directly overwrite us without even > > commenting here. I strongly disagree with that procedure but, ok, I will > > keep it as-is but, please, next time at least ping us or similar: > > Maybe because you ignored a severe bug for 3 months. > I doubt as I didn't ignore it and QA team wasn't ever CCed here > (In reply to Michał Górny from comment #16) > > I've updated the ebuild and removed the mask. Hope everyone's going to be > > happy now. > > Thanks for finally applying my patch :). I agree with the final change anyway as looks to handle all cases