Description of problem:

Upgrading from 34 to 35, if the system has a customized /etc/pipewire/pipewire.conf, the system will appear to have no sound due to two copies of pipewire running at the same time. This is because F34 used context.exec inside pipewire.conf to start pipewire-media-session, but in F35 commented that line out in favor of using a systemd service. Here is the change in /usr/share/pipewire/pipewire.conf from F34 to F35:

<     { path = "/usr/bin/pipewire-media-session" args = "" }
---
>     #{ path = "/usr/bin/pipewire-media-session" args = "" }

This appears to be a significant downside of of the choice to put the config file into /usr/share/, a data directory, and force users who want to adjust config to make a complete copy inside /etc/. I did just that to adjust one setting, which means I have an unmanaged config file, and the package manager at upgrade time had no way of detecting or alerting me to an important change. See also: https://bugzilla.redhat.com/show_bug.cgi?id=1963939

Version-Release number of selected component (if applicable):

pipewire-0.3.40-1.fc35.x86_64

How reproducible:

always

Steps to Reproduce:
1. Install Fedora 34
2. Change a setting in pipewire.conf, which required making a complete copy of it in /etc/
3. Upgrade to Fedora 35

Actual results:

Sound no longer works. Gnome's sound settings will show no devices. On investigation, you'll find two pipewire processes running.

Expected results:

Sound keeps working.

Additional info:

I think this would be a good candidate for the "Common F35 bugs" wiki page, since it's likely to affect anyone who needed to change any setting in pipewire.conf while using F34. There are already two other common bugs listing reasons sound might break after upgrade. I'm happy to write a blurb there if that's helpful, or would happily defer to someone else if you prefer.

https://fedoraproject.org/wiki/Common_F35_bugs