The upgrade isn’t clean… When updating a template that had pulseaudio (and pulseaudio-qubes) installed, apt dist-upgrade skips updating qubes-whonix-workstation-packages-recommended, I assume because that requires removing pulseaudio-qubes. But when doing explicit apt install qubes-whonix-workstation-packages-recommended, it does offer an update and removal of pulseaudio-qubes.
Honestly, I’m not sure how to handle this situation best. TBH, I’m not sure why it wasn’t an issue in release upgrade R4.1 → R4.2. We did need explicit pulseaudio-pipewire step in the upgrade tool for Fedora templates, but not for Debian. Maybe it’s due to which package has those dependencies (pipewire-qubes has Conflicts: pulseaudio-qubes and Recommends: pipewire-pulse - so, it’s the same package pulling one and removing the other, while on Whonix, due to --no-install-recommends it’s a different package pulling in pipewire-pulse than removing pulseaudio-qubes). I don’t fully understand this, could be something else. One thing to try might be adding Conflicts: pulseaudio-qubes to qubes-whonix-workstation-packages-recommended, but see below.
And to make things worse, pipewire-qubes isn’t a thing on R4.1 yet, which leads to another dependency issue… This issue is relevant only for a little less than 3 months (until R4.1 EOL), but still.
Maybe, for the time being, the better approach would be a less strict migration, like Depends: pipewire-qubes | pulseaudio-qubes, so it would choose pipewire for new builds, but not switch to it if pulseaudio is already installed? But in that case, I’m not sure what to do about pipewire-pulse requirement, does Debian support grouping in dependencies like Depends: (pipewire-qubes, pipewire-pulse) | pulseaudio-qubes ? If not, I guess it can be written as Depends: pipewire-qubes | pulseaudio-qubes, pipewire-pulse | pulseaudio-qubes. As for the conflict with pulseaudio, I’m not sure how to do it. Adding Conflicts: pulseaudio-qubes will break audio on R4.1. Maybe some Conflicts: pulseaudio-qubes | pipewire-qubes would work? Probably not…
The underlying issue with this migration is that pipewire and pulseaudio cannot run at the same time - there can be only one audio daemon connecting to dom0 (or other audiovm). Currently it’s achieved with package conflict. Maybe a more robust solution would be to avoid package conflict and add some runtime detection (if pulseaudio-qubes detects pipewire installed/enabled, it will not start)?
Any preference?
I do have R4.1 and R4.2 test systems, with Whonix Workstation 17 template from before this change, so I can test various options, for example if you upload some package to try to some repository (developers one?).