Hello, I switched to pipewire yesterday and wanted it to replace everything it can from pulseaudio, so I had the `pipewire-alsa` USE flag enabled. It installed properly. Although, when I tried updating today there was some conflicts that were a little bit difficult to untangle: I had pulseaudio with the alsa-plugin USE flag, and that was the root cause. Do you think it's a good idea to add a blocker for pipewire when pulseaudio has the alsa-plugin enabled ? Thanks!
Please be a bit more specific. What exact USE flags had you set the involved packages for? What was the actual error message? Can you please provide the output of "emerge --info pulseaudio pipewire alsa-plugins"?
Created attachment 721074 [details] Initial flag state before doing flag changes So this is the initial state I start from before I want to enable USE=pipewire-alsa for pipewire.
Created attachment 721086 [details] output of sudo emerge update after flag change So this is the ouput of "sudo emerge --ask --verbose --update --deep --changed-use --with-bdeps=y @world" after doing the following USE change media-video/pipewire pipewire-alsa It looks complicated, but it simply gets fixed by doing this: media-video/pipewire pipewire-alsa media-sound/pulseaudio -alsa-plugin Which makes one think that media-video/pipewire[pipewire-alsa] should block media-sound/pulseaudio[alsa-plugin] instead of block edia-plugins/alsa-plugins[pulseaudio]
My understanding is that the current ebuild is correctly blocking the part that can lead to issues - the package actually installing the plugin, which could be installed on its own, so blocking another package did not make sense. What's happening in this case is that Portage might have allowed to install a package with only partially resolved dependencies and not having checked that the full dependency graph would produce a conflict. Not sure why or how that happened though. I guess it might be possible to additionally also block the media-sound/pulseaudio[alsa-plugin] even though we don't really have any beef with it (it's a virtual IUSE that does not affect the package itself).
> My understanding is that the current ebuild is correctly blocking the part that can lead to issues - the package actually installing the plugin You are right, my initial suggestion of swapping the blockers is not good. > What's happening in this case is that Portage might have allowed to install a package with only partially resolved dependencies and not having checked that the full dependency graph would produce a conflict. Not sure why or how that happened though. I think the initial state I start from does not have any conflict: - I did not manually install media-plugins/alsa-plugins[pulseaudio] so it's being pulled only as a dependency with "default" flags - I do have media-sound/pulseaudio[alsa-plugin] and media-video/pipewire[-pipewire-alsa] emerged - Changing the use flag to +pipewire-alsa media-video/pipewire causes the blocker: it is not a bug, it's just simply a bit difficult to understand what's going on. And I think it can be made simpler with an additional blocker, maybe. I do not know what kind of error message would be displayed with it, I need to test. > I guess it might be possible to additionally also block the media-sound/pulseaudio[alsa-plugin] even though we don't really have any beef with it (it's a virtual IUSE that does not affect the package itself). I think it makes sense to additionally make media-video/pipewire[pipewire-alsa] block media-sound/pulseaudio[alsa-plugin] as the latter pulls media-plugins/alsa-plugins[pulseaudio], which conflicts with media-video/pipewire[pipewire-alsa].
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=431a2f1ce462c3b915184beac83eb73181fcf2cd commit 431a2f1ce462c3b915184beac83eb73181fcf2cd Author: Igor V. Kovalenko <igor.v.kovalenko@gmail.com> AuthorDate: 2022-04-30 16:18:09 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-05-01 19:48:53 +0000 media-video/pipewire: Drop alsa-plugins[pulseaudio] blocker Currently alsa-plugins[pulseaudio] installs pulse plugin which is only enabled in alsa lib configuration if plugin can access pulseaudio server in runtime. This is implemented using a runtime conf hook in 51-pulseaudio-probe.conf Alsa lib runtime conf hooks are run after all static configuration is applied. This causes a problem to coexistence of pipewire-alsa and pulse plugin: - normally, pipewire-pulse is enabled which provides pulseaudio server connection to libpulse users - since pulseaudio server is accessible, pulse conf hook will override alsa pcm.!default and ctl.!default to use pulse plugin. To work around this, change pipewire-alsa plugin configuration from static conf to conf hook which will run after pulse conf hook. To make sure user can still override default device, make sure this new conf hook will also load /etc/asound.conf and ~/.asoundrc again like it is done by pulse conf hook. Since pipewire plugin will take precedence now if pipewire-alsa is installed, drop the blocker with media-sound/alsa-plugins[pulseaudio] Closes: https://bugs.gentoo.org/799881 Closes: https://bugs.gentoo.org/791499 Signed-off-by: Igor V. Kovalenko <igor.v.kovalenko@gmail.com> Closes: https://github.com/gentoo/gentoo/pull/25269 Signed-off-by: Sam James <sam@gentoo.org> .../pipewire/files/99-pipewire-default-hook.conf | 17 +++++++++++++++++ ...pipewire-0.3.51.ebuild => pipewire-0.3.51-r1.ebuild} | 8 ++++++-- 2 files changed, 23 insertions(+), 2 deletions(-)
