I use Pulse-audio and installing the `libspa` package was the final step in getting Blue Tooth to work as-intended on my fresh setup. Installing that package had no other dependencies other than itself that weren't already installed
I cannot see how that works. All that libspa-0.2-bluetooth does is put a plugin library in place that gets picked up by PipeWire. You can double check what you're actually using with
systemctl --user status pulseaudio.service pulseaudio.socket pipewire.service pipewire.socket pipewire-pulse.service pipewire-pulse.socket
I'm pretty sure that either you're actually using PipeWire or not having the package does not really make a difference. Otherwise I would not understand what's happening at all.
Seems like an easy fix with no downsides, especially as `libspa` doesn't depend on a full Pipe Wire installation as far as I can tell.
That is correct, it only pulls in PipeWire plugin libraries. However, as I already mentioned, the opposite is the case for pulseaudio-module-bluetooth: It depends on pulseaudio. Recommending both thus leads to installing pulseaudio for PipeWire users that follow the recommendation.
That was actually the reason to add the PipeWire alternative initially after Ubuntu flavors started switching to PipeWire in 23.04. As at least Ubuntu Cinnamon, MATE, Lubuntu and Xubuntu include both blueman and PipeWire then and the images follow recommendations, they'd also have pulseaudio or even fail to resolve the recommendations due to conflicts. The solution is to recommend the Bluetooth plugin for either pulseaudio *or* PipeWire and if one of them is already in place – the PipeWire one in case of those images – we're good.
I agree that it is not ideal that users with a sound server but no Bluetooth plugin in place might end up with a plugin for the wrong server, but I think the dependency system is too limited to solve that properly. It is definitely worse that users of PipeWire would end up with a pulseaudio installation (whose resolution may fail) if we'd recommend both.
