Re: use of Recommends by vlc to force users to use pipewire
On Fri, 27 May 2022 at 01:35:51 +0200, Vincent Lefevre wrote:
> with the installation of
> vlc-plugin-pipewire, VLC was automatically using pipewire
If vlc-plugin-pipewire is prioritized higher than other audio backends,
then I can see how that could happen. It's probably premature for
vlc-plugin-pipewire to be prioritized higher than PulseAudio or ALSA in
Debian.
The dependency graph around this stuff is complicated, particularly in
a distribution like Debian where the answer to "do we try to support A
or B?" is always "yes". Some early-adopter distributions have switched
to Pipewire as their preferred audio service, replacing PulseAudio,
and in *those* distributions, it would make sense to prioritize
vlc-plugin-pipewire ahead of other audio backends - but Pipewire was not
sufficiently mature to replace PulseAudio in bullseye, and it remains
to be seen whether it will be sufficiently mature to replace PulseAudio
in bookworm.
If Pipewire was only an audio service, then the right thing to do would be
to make sure it was completely optional and not pulled in by depenencies,
but it's a video service too, and during a global pandemic with a lot of
people working and socializing remotely, not having working screen-sharing
or screencasting in GNOME/KDE (together with not having working webcams
in sandboxed Flatpak/Snap apps) seemed like a sufficiently major issue
to make Pipewire worth the headaches it can cause.
> and apparently ditto with ogg123 (via ALSA, which I had as the default)
I don't know why that would be. The Pipewire module for libasound is in
pipewire-audio-client-libraries, which nothing depends on.
Could it be the case that the chain of Recommends pulled in wireplumber
(which Recommends pipewire-pulse) instead of the preferred alternative
pipewire-media-session (which was not always listed first, see #999363),
resulting in pipewire-pulse taking over audio routing from PulseAudio?
> However, for the support of bluetooth devices, libspa-0.2-bluetooth
> is needed, but it isn't even pulled when pipewire is installed!
That's needed for Bluetooth audio, *if* you are using Pipewire for audio,
which (as a distribution) we are not yet aiming to do. It isn't needed
(or useful) if you are only using Pipewire as a video multiplexer.
pipewire-pulse should probably have a Recommends on libspa-0.2-bluetooth,
if people consider Bluetooth audio to be sufficiently important to
justify that (of course, every critical feature for one user is considered
"bloat" by someone else, so we can't win). pipewire probably shouldn't,
until such time as we are ready to recommend Pipewire as a replacement
for PulseAudio.
> But xdg-desktop-portal just depends
> on the libpipewire-0.3-0 library package. If it needs more than
> the library, then I suppose that it should also recommend pipewire
> directly and not expect that the library will do it.
Perhaps. If I add that Recommends, how many angry bug reports are we
going to get accusing me of forcing people to use Pipewire against
their will? Conversely, if installing xdg-desktop-portal doesn't
pull in pipewire-bin by any chain of Recommends, how many angry bug
reports are we going to get because screen sharing doesn't work in a
apparently-unrelated Flatpak app or web browser, which in fact needs
pipewire for behind-the-scenes reasons that are not visible to a typical
user?
smcv
Reply to: