On Thu, 26 May 2022 at 17:21:27 +0200, Vincent Lefevre wrote:
> Here, this could be
>
> Recommends: pipewire | pulseaudio
Those are not interchangeable.
pipewire started as a multiplexer for video streams, and only later
gained audio capabilities. The reason most people with pipewire will
have it installed is that it's necessary when doing screen-sharing or
screencasting from a Wayland environment like GNOME.
If you're *also* using pipewire as an audio multiplexing server, which
is not the default for any installation of Debian yet (but might be in
future), then you will also need pipewire-pulse, which has two purposes:
* it configures the pipewire service to open the audio device;
* it provides a separate PulseAudio-compatible server which acts as a
wire-protocol-compatible replacement for pulseaudio
Without pipewire-pulse, pipewire is only a video multiplexer, not an
audio multiplexer.
pipewire is actually more like a metapackage, which pulls in the packages
that are needed to have Pipewire actually work for a particular library
architecture (libpipewire-0.3-0 cannot pull in libpipewire-0.3-modules
itself, because that would be a circular dependency), together with the
pipewire service from the primary architecture (pipewire-bin).
> Indeed, for a remote VM, it is silly to recommend a sound server,
> just because a library appears in the chain of dependencies:
>
> joooj:~> apt-get install -s atril | grep '^Inst pipewire'
It looks like that's happening because atril depends on WebKitGTK, a
relatively complete web browser engine, which uses xdg-desktop-portal
to invoke per-user services across a sandbox boundary (so that it can
provide the web APIs people expect from it, without having arbitrary
websites able to access your webcam without your permission).
xdg-desktop-portal depends on pipewire because one of the services it
provides is access to webcams, and another is screen-sharing and
screencasting. Both of those use the Pipewire video protocol to get the
actual frames across the sandbox boundary.
Maybe Atril never actually uses WebKitGTK to access arbitrary websites,
but WebKitGTK is a fully-featured web browser engine, so it has to
be prepared to do anything that an arbitrary website expects to work,
and that includes (for example) the Jitsi web frontend.
> Ditto for the gnucash accounting software
Same dependency here: it depends on WebKitGTK.
That's an incredibly interesting explanation. Should be part of a wiki somewhere !