Re: use of Recommends by vlc to force users to use pipewire

[Joey Hess]

Vincent Lefevre wrote:
> So there's something contradictory. If the pipewire service alone
> doesn't take control of audio over pulseaudio, then the only culprit
> would be pipewire-media-session. Or what? A bug in pipewire, which
> would actually take control of audio even without pipewire-pulse?

I can confirm, I just upgraded (unstable) and vlc began using pipewire for
playback based on some error messages.

I did not have pipewire-pulse installed. Removing
pipewire-bin pipewire pipewire-media-session fixed it.

[558fb18b0660] main libvlc: Running vlc with the default interface. Use 
'cvlc' to use vlc without interface.
[558fb197bd10] pipewire audio output error: stream error: no node available

-- 
see shy jo


signature.asc
Description: PGP signature

Re: use of Recommends by vlc to force users to use pipewire

[Vincent Lefevre]

On 2022-05-31 14:55:44 +0500, Andrey Rahmatullin wrote:
> On Tue, May 31, 2022 at 11:43:06AM +0200, Vincent Lefevre wrote:
> > Indeed, this is what happened with pipewire 0.3.39-1, as I can see
> > in my dpkg logs and the changelog:
> > 
> >   * Change priority order between pipewire-media-session and wireplumber,
> >   WirePlumber is now the recommended session manager.
> > 
> > and this is what led to the pipewire-pulse installation.
> So "pipewire-media-session was installed" is indeed irrelevant.

No, because pipewire-pulse got removed a bit later. This was in
October 2021. Since then, pipewire-pulse was no longer installed.
But Dylan Aïssi said:

| Indeed, but pipewire service doesn't take control of audio over
| pulseaudio. Only pipewire-pulse does that.
| So, if you don't want to use pipewire for audio, then don't install
| pipewire-pulse and that's it.

So there's something contradictory. If the pipewire service alone
doesn't take control of audio over pulseaudio, then the only culprit
would be pipewire-media-session. Or what? A bug in pipewire, which
would actually take control of audio even without pipewire-pulse?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: use of Recommends by vlc to force users to use pipewire

[Vincent Lefevre]

On 2022-05-31 11:43:06 +0200, Vincent Lefevre wrote:
> Anyway, when I upgraded the vlc package two weeks ago, this had the
> effect that PulseAudio was no longer used as the sound server (for
> both vlc and ogg123), though pipewire was already installed (due to
> a Recommends from libpipewire-0.3-0, itself due to a Depends from
> xdg-desktop-portal). The only new package was vlc-plugin-pipewire,
> due to
> 
>   * debian/control: Recommend vlc-plugin-pipewire
> 
> pipewire-pulse was not installed.

A clarification about this point: Concerning ogg123, it was actually
using the ALSA device (I had default_driver=alsa in /etc/libao.conf),
and before the vlc upgrade, this was automatically forwarding the
stream to PulseAudio (something like that, I don't know the internals).
It is only after the upgrade of the vlc package[*] that things got
really broken with ogg123 too.

[*] I also used VLC after the upgrade, and I suspect that this had
the effect to change something in the configuration, as neither vlc
nor ogg123 was using PulseAudio any longer, as seen in pavucontrol.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: use of Recommends by vlc to force users to use pipewire

[Andrey Rahmatullin]

On Tue, May 31, 2022 at 11:43:06AM +0200, Vincent Lefevre wrote:
> > > > >  a) pipewire package enables pipewire service by default
> > > > 
> > > > Indeed, but pipewire service doesn't take control of audio over
> > > > pulseaudio. Only pipewire-pulse does that.
> > > 
> > > This is incorrect. The pipewire-pulse package was not installed
> > > at all (pipewire-pulse had been installed automatically in
> > > October 2021 due to dependencies, but the change was reverted,
> > > and the package got removed on my machine 3 days later).
> 
> Sorry. Actually it got removed because I downgraded the pipewire
> packages back to the previous version (it's clearer with the
> /var/log/apt/term.log* log files).
> 
> > > I don't know whether this could cause the issue, but
> > > pipewire-media-session was installed, because pipewire-bin
> > > recommends it. There were already issues with it in the past:
> > What issues?
> 
> The ones mentioned below ("Closes: ...").
They are about pipewire-media-session vs wireplumber and/or affect people
installing pipewire-pulse as far as I can see.

> > > https://tracker.debian.org/news/1271014/accepted-pipewire-0339-3-source-into-unstable/
> > > which says:
> > > 
> > >* Remove pipewire-media-session from Recommends.
> > >(Closes: #995116, #996994, #997859)
> > The context of this was "replace pipewire-media-session with wireplumber"
> 
> Indeed, this is what happened with pipewire 0.3.39-1, as I can see
> in my dpkg logs and the changelog:
> 
>   * Change priority order between pipewire-media-session and wireplumber,
>   WirePlumber is now the recommended session manager.
> 
> and this is what led to the pipewire-pulse installation.
So "pipewire-media-session was installed" is indeed irrelevant.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: use of Recommends by vlc to force users to use pipewire

[Vincent Lefevre]

On 2022-05-31 14:04:18 +0500, Andrey Rahmatullin wrote:
> On Tue, May 31, 2022 at 10:55:55AM +0200, Vincent Lefevre wrote:
> > > >  a) pipewire package enables pipewire service by default
> > > 
> > > Indeed, but pipewire service doesn't take control of audio over
> > > pulseaudio. Only pipewire-pulse does that.
> > 
> > This is incorrect. The pipewire-pulse package was not installed
> > at all (pipewire-pulse had been installed automatically in
> > October 2021 due to dependencies, but the change was reverted,
> > and the package got removed on my machine 3 days later).

Sorry. Actually it got removed because I downgraded the pipewire
packages back to the previous version (it's clearer with the
/var/log/apt/term.log* log files).

> > I don't know whether this could cause the issue, but
> > pipewire-media-session was installed, because pipewire-bin
> > recommends it. There were already issues with it in the past:
> What issues?

The ones mentioned below ("Closes: ...").

> > https://tracker.debian.org/news/1271014/accepted-pipewire-0339-3-source-into-unstable/
> > which says:
> > 
> >* Remove pipewire-media-session from Recommends.
> >(Closes: #995116, #996994, #997859)
> The context of this was "replace pipewire-media-session with wireplumber"

Indeed, this is what happened with pipewire 0.3.39-1, as I can see
in my dpkg logs and the changelog:

  * Change priority order between pipewire-media-session and wireplumber,
  WirePlumber is now the recommended session manager.

and this is what led to the pipewire-pulse installation.

> and it was rolled back in the next upload as you can see in d/changelog.

More precisely, pipewire-media-session was removed from Recommends
in pipewire 0.3.39-3. I upgraded to this version, and pipewire-pulse
was installed again. So, I downgraded again, so that pipewire-pulse
got removed again.

Then the rollback was done in pipewire 0.3.39-4:

  * Re-add pipewire-media-session as an alternative to Wireplumber,
  it is now back in the archive as a separate source package.

and pipewire-pulse was no longer installed again on my machine.

Anyway, when I upgraded the vlc package two weeks ago, this had the
effect that PulseAudio was no longer used as the sound server (for
both vlc and ogg123), though pipewire was already installed (due to
a Recommends from libpipewire-0.3-0, itself due to a Depends from
xdg-desktop-portal). The only new package was vlc-plugin-pipewire,
due to

  * debian/control: Recommend vlc-plugin-pipewire

pipewire-pulse was not installed.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: use of Recommends by vlc to force users to use pipewire

[Andrey Rahmatullin]

On Tue, May 31, 2022 at 10:55:55AM +0200, Vincent Lefevre wrote:
> > >  a) pipewire package enables pipewire service by default
> > 
> > Indeed, but pipewire service doesn't take control of audio over
> > pulseaudio. Only pipewire-pulse does that.
> 
> This is incorrect. The pipewire-pulse package was not installed
> at all (pipewire-pulse had been installed automatically in
> October 2021 due to dependencies, but the change was reverted,
> and the package got removed on my machine 3 days later).
> 
> I don't know whether this could cause the issue, but
> pipewire-media-session was installed, because pipewire-bin
> recommends it. There were already issues with it in the past:
What issues?

> https://tracker.debian.org/news/1271014/accepted-pipewire-0339-3-source-into-unstable/
> which says:
> 
>* Remove pipewire-media-session from Recommends.
>(Closes: #995116, #996994, #997859)
The context of this was "replace pipewire-media-session with wireplumber"
and it was rolled back in the next upload as you can see in d/changelog.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: use of Recommends by vlc to force users to use pipewire

[Vincent Lefevre]

On 2022-05-30 14:30:38 +0200, Dylan Aïssi wrote:
> Le lun. 30 mai 2022 à 12:55, Jonas Smedegaard  a écrit :
> >  a) pipewire package enables pipewire service by default
> 
> Indeed, but pipewire service doesn't take control of audio over
> pulseaudio. Only pipewire-pulse does that.

This is incorrect. The pipewire-pulse package was not installed
at all (pipewire-pulse had been installed automatically in
October 2021 due to dependencies, but the change was reverted,
and the package got removed on my machine 3 days later).

I don't know whether this could cause the issue, but
pipewire-media-session was installed, because pipewire-bin
recommends it. There were already issues with it in the past:

https://tracker.debian.org/news/1271014/accepted-pipewire-0339-3-source-into-unstable/
which says:

   * Remove pipewire-media-session from Recommends.
   (Closes: #995116, #996994, #997859)

But pipewire-bin still has:

Recommends: dbus-user-session, pipewire-media-session | wireplumber, rtkit

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: use of Recommends by vlc to force users to use pipewire

[Marvin Renich]

* Dylan Aïssi  [220530 08:31]:
> Le lun. 30 mai 2022 à 12:55, Jonas Smedegaard  a écrit :
> >
> >  a) pipewire package enables pipewire service by default
> 
> Indeed, but pipewire service doesn't take control of audio over
> pulseaudio. Only pipewire-pulse does that.
> So, if you don't want to use pipewire for audio, then don't install
> pipewire-pulse and that's it.
> What is the real issue with pipewire service?
> 
> libpipewire recommends pipewire for a reason [1], do you mean this is
> not a good reason?
> 
> [1] https://salsa.debian.org/utopia-team/pipewire/-/merge_requests/1

Jonas is exactly correct.  Because it is a very common case for a user
to need to have libpipewire installed but want to _not_ have pipewire
installed, libpipewire MUST NOT Recommed pipewire.

"Recommends"
   This declares a strong, but not absolute, dependency.

   The "Recommends" field should list packages that would be found
   together with this one in all but unusual installations.

pipewire clearly _does not_ satisfy this definition.  It is up to the
application that links with libpipewire to determine if pipewire should
be a Depends, Recommends, Suggests, or none of these.

As an alternative, you could separate libpipewire into libpipewire
(non-audio-server API) and libpipewire-pulse (audio server API).  Have
libpipewire-pulse Suggest, but not Recommend, pipewire-pulse.
Applications that want to use whatever sound server the user has
installed will link with libpipewire-pulse instead of libpipewire, and
will not automatically pull in pipewire or pipewire-pulse.  However, I'm
not sure if this would or would not leave the non-audio libpipewire in
the same position that the current libpipewire is in.

To answer your question above, I presume that one of libpipewire's
functions is to determine whether specific pipewire services are
available, perhaps by calling an init function and checking the result.
This clearly obviates the reason stated in the above link, and adding
the Recommends violates the policy definition and creates undesired
setups for users in many situations.  So, no, that is not a good reason.

...Marvin

Re: use of Recommends by vlc to force users to use pipewire

[Paul Wise]

On Mon, 2022-05-30 at 14:30 +0200, Dylan Aïssi wrote:

> libpipewire recommends pipewire for a reason [1], do you mean this is
> not a good reason?
> 
> [1] https://salsa.debian.org/utopia-team/pipewire/-/merge_requests/1

In the patch Philip Withnall wrote:

> libpipewire dlopens modules from pipewire (such as `libspa-support.so`),
> and relies on being able to connect to the pipewire daemon to function.

Since libspa-support.so is in libspa-0.2-modules not in pipewire,
probably that should be Recommended too?

$ apt-file search libspa-support.so
libspa-0.2-modules: /usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-support.so

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: use of Recommends by vlc to force users to use pipewire

[Jonas Smedegaard]

Quoting Dylan Aïssi (2022-05-30 14:30:38)
> Le lun. 30 mai 2022 à 12:55, Jonas Smedegaard  a écrit :
> >
> >  a) pipewire package enables pipewire service by default
> 
> Indeed, but pipewire service doesn't take control of audio over
> pulseaudio. Only pipewire-pulse does that.
> So, if you don't want to use pipewire for audio, then don't install
> pipewire-pulse and that's it.
> What is the real issue with pipewire service?
> 
> libpipewire recommends pipewire for a reason [1], do you mean this is
> not a good reason?
> 
> [1] https://salsa.debian.org/utopia-team/pipewire/-/merge_requests/1

Yes, that is exactly what I mean.

All the libraries in Debian linking against libmariadb3 similary
"relies on being able to connect to [MariaDB] to function", yet none of
them recommend the package mariadb - because those libraries do not
actually *use* mariadb, it is the applications linking against those
libraries that use mariadb, and those applications can each decide how
important is is for said functionality to work - whether it should be a
dependency, a recommendation, or a suggestion.

Declaring a package relation from a library to a daemon forces *all*
consumers of that library to have equal strength relationship, which
almost always wrong.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: use of Recommends by vlc to force users to use pipewire

[Dylan Aïssi]

Le lun. 30 mai 2022 à 12:55, Jonas Smedegaard  a écrit :
>
>  a) pipewire package enables pipewire service by default

Indeed, but pipewire service doesn't take control of audio over
pulseaudio. Only pipewire-pulse does that.
So, if you don't want to use pipewire for audio, then don't install
pipewire-pulse and that's it.
What is the real issue with pipewire service?

libpipewire recommends pipewire for a reason [1], do you mean this is
not a good reason?

[1] https://salsa.debian.org/utopia-team/pipewire/-/merge_requests/1

Re: use of Recommends by vlc to force users to use pipewire

[Jonas Smedegaard]

Quoting Sebastian Ramacher (2022-05-30 12:08:44)
> On 2022-05-30 10:43:58 +0200, Vincent Lefevre wrote:
> > On 2022-05-28 10:41:34 +0200, Sebastian Ramacher wrote:
> > > On 2022-05-28 01:27:13 +0200, Vincent Lefevre wrote:
> > > > On 2022-05-27 12:34:26 +0100, Simon McVittie wrote:
> > [...]
> > > > > 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.
> > > > 
> > > > The issue appeared automatically with the upgrade of the vlc package.
[...]
> > My comment was on "until such time as we are ready to recommend
> > Pipewire as a replacement for PulseAudio". If Debian is not ready
> > to use Pipewire as a replacement for PulseAudio, then VLC shouldn't
> > try to use Pipewire by default instead of PulseAudio. So that would
> > be a bug in VLC.
> 
> Let me clear this up a bit:
> 
> * vlc does not use pipewire by default.
[...]
> * vlc-plugin-pipewire depends on libpipewire-0.3 and that's it.

So essentially...:

 a) pipewire package enables pipewire service by default

 b) libpipewire* package recommends pipewire

 c) vlc recommends libpipewire

Effectively, installing vlc enables pipewire service by default, despite
vlc not intending that to happen.

To allow packages *support* a functionality by default, separately from
*enabling* that functionality by default, libraries need to stop
recommending their consuming service.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: use of Recommends by vlc to force users to use pipewire

[Sebastian Ramacher]

On 2022-05-30 10:43:58 +0200, Vincent Lefevre wrote:
> On 2022-05-28 10:41:34 +0200, Sebastian Ramacher wrote:
> > On 2022-05-28 01:27:13 +0200, Vincent Lefevre wrote:
> > > On 2022-05-27 12:34:26 +0100, Simon McVittie wrote:
> [...]
> > > > 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.
> > > 
> > > The issue appeared automatically with the upgrade of the vlc package.
> > > 
> > > > 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.
> > > 
> > > So why did Sebastian Ramacher reassign bug 1011035 to pipewire?
> > > 
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011035#22
> > 
> > If pipewire-pulse is the better place for this relationship, feel free
> > to reassign it.
> 
> My comment was on "until such time as we are ready to recommend
> Pipewire as a replacement for PulseAudio". If Debian is not ready
> to use Pipewire as a replacement for PulseAudio, then VLC shouldn't
> try to use Pipewire by default instead of PulseAudio. So that would
> be a bug in VLC.

Let me clear this up a bit:

* vlc does not use pipewire by default. vlc always has included multiple
  audio output plugins. vlc-plugin-base (which vlc depends on) installs
  plugins for alsa, pulseaudio and others. vlc then tries to auto-detect
  the most suitable audio plugin. If it detects pulseaudio, it will use
  the pulseaudio plugin, etc.

  Now, if vlc-plugin-pipewire is installed, it will also check if
  pipewire is running as sound server and prefer that over the
  pulseaudio plugin.

  Users have always been able to override the audio output via the
  command line or vlc's settings.

* bin:vlc aims to give a suitable default installation for desktop use.
  It depends on the plugins that I deem absolutly necessary for typical
  desktop usage (video output plugins, hardware decoding plugins, access
  plugins, the Qt UI plugin, ...). vlc recommends plugin packages
  which have additional access plugins, video processing plugins, etc
  that are not necessary for the core functionality but users might
  expect or improve the vlc experience. Furthermore, it suggest plugins
  for more specialiced use-cases.

  If users don't need or want the extended functionalities that the
  recommended or suggested plugins provide, they are free to uninstall/
  not install them without breaking the core functionality of (desktop)
  vlc.

* As with the switch to pulseaudio many years ago, the recommended vlc
  installation now provides the corresponding plugin for the switch to
  pipewire. So if a user has completely switched or wants to switch to
  pipewire, they get the corresponding plugin. But even if the user
  doesn't switch to pipewire (or is not even using pulseaudio), they
  will also have the plugins installed for that: the alsa and the
  pulseaudio plugins.

  Also similar to the pulseaudio switch, the new plugin is a separate
  binary package at first and will sooner or later move to
  vlc-plugin-base (most likely with the release of vlc 4.0).

* vlc-plugin-pipewire depends on libpipewire-0.3 and that's it. In
  bookworm, I expect that more and more packages will depend on
  libpipewire-0.3 - for example, see anything that does screen recording
  such as obs-studio. Whether or not libpipewire-0.3 should have a
  recommends-chain to pipewire-pulse is a different story, unreleated
  to vlc, and is already discussed at length in other parts of this
  thread.


Cheers
-- 
Sebastian Ramacher

Re: use of Recommends by vlc to force users to use pipewire

[Vincent Lefevre]

On 2022-05-28 10:41:34 +0200, Sebastian Ramacher wrote:
> On 2022-05-28 01:27:13 +0200, Vincent Lefevre wrote:
> > On 2022-05-27 12:34:26 +0100, Simon McVittie wrote:
[...]
> > > 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.
> > 
> > The issue appeared automatically with the upgrade of the vlc package.
> > 
> > > 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.
> > 
> > So why did Sebastian Ramacher reassign bug 1011035 to pipewire?
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011035#22
> 
> If pipewire-pulse is the better place for this relationship, feel free
> to reassign it.

My comment was on "until such time as we are ready to recommend
Pipewire as a replacement for PulseAudio". If Debian is not ready
to use Pipewire as a replacement for PulseAudio, then VLC shouldn't
try to use Pipewire by default instead of PulseAudio. So that would
be a bug in VLC.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: use of Recommends by vlc to force users to use pipewire

[Sebastian Ramacher]

On 2022-05-28 01:27:13 +0200, Vincent Lefevre wrote:
> On 2022-05-27 12:34:26 +0100, Simon McVittie wrote:
> > 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.
> 
> So I suppose that the solution should be that PulseAudio have the
> priority over Pipewire.
> 
> > > 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.
> 
> It has never been installed.
> 
> > 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?
> 
> The wireplumber package was installed from 2021-10-26 to 2021-10-29
> only. So, perhaps ogg123 was using something else. But the ogg123
> audio stream was not appearing in pavucontrol, and the sound was
> sent to the speaker of my laptop instead of the bluetooth speakers.
> 
> > > 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.
> 
> The issue appeared automatically with the upgrade of the vlc package.
> 
> > 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.
> 
> So why did Sebastian Ramacher reassign bug 1011035 to pipewire?
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011035#22

If pipewire-pulse is the better place for this relationship, feel free
to reassign it.

Cheers

> 
> > > 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?
> 
> Fewer: This is already an issue because xdg-desktop-portal depends
> on libpipewire-0.3-0, which recommends pipewire. The advantage would
> be that packages just depending on libpipewire-0.3-0 would not pull
> pipewire. So, this would solve the pipewire issue in some cases.
> 
> Said otherwise, this would not change anything for xdg-desktop-portal,
> but could improve things for other packages (if xdg-desktop-portal and
> other packages pulling pipewire are not installed).
> 
> -- 
> Vincent Lefèvre  - Web: 
> 100% accessible validated (X)HTML - Blog: 
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
> 

-- 
Sebastian Ramacher

Re: use of Recommends by vlc to force users to use pipewire

[Vincent Lefevre]

On 2022-05-27 12:34:26 +0100, Simon McVittie wrote:
> 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.

So I suppose that the solution should be that PulseAudio have the
priority over Pipewire.

> > 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.

It has never been installed.

> 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?

The wireplumber package was installed from 2021-10-26 to 2021-10-29
only. So, perhaps ogg123 was using something else. But the ogg123
audio stream was not appearing in pavucontrol, and the sound was
sent to the speaker of my laptop instead of the bluetooth speakers.

> > 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.

The issue appeared automatically with the upgrade of the vlc package.

> 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.

So why did Sebastian Ramacher reassign bug 1011035 to pipewire?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011035#22

> > 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?

Fewer: This is already an issue because xdg-desktop-portal depends
on libpipewire-0.3-0, which recommends pipewire. The advantage would
be that packages just depending on libpipewire-0.3-0 would not pull
pipewire. So, this would solve the pipewire issue in some cases.

Said otherwise, this would not change anything for xdg-desktop-portal,
but could improve things for other packages (if xdg-desktop-portal and
other packages pulling pipewire are not installed).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: use of Recommends by vlc to force users to use pipewire

[Alberto Garcia]

On Fri, May 27, 2022 at 02:18:10AM +0200, Vincent Lefevre wrote:
> > In this case you need the portal in order to have access to the
> > font settings:
> IMHO, such explanations could be useful to users, who may wonder why
> xdg-desktop-portal-gtk is recommended or why some features are not
> available (in case the Recommends got broken, but this is unnoticed
> by the user). That could be some file under the
> /usr/share/doc/libwebkit2gtk-4.0-37 directory.

I understand that there's always room for a more detailed explanation,
but the changelog.Debian.gz file shipped with the package already
explains why the dependency was added and references the original bug
report with all the details.

Berto

Re: use of Recommends by vlc to force users to use pipewire

[Simon McVittie]

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

Re: use of Recommends by vlc to force users to use pipewire

[Vincent Lefevre]

On 2022-05-26 23:55:02 +, Alberto Garcia wrote:
> On Fri, May 27, 2022 at 01:03:57AM +0200, Jonas Smedegaard wrote:
> > > It was actually due to a problem in Evolution that we made WebKitGTK
> > > depend on xdg-desktop-portal (later downgraded to a recommendation):
> > > 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1845743
> > > https://bugs.webkit.org/show_bug.cgi?id=213148
> > 
> > Ok, so Evolution uses sandboxing
> 
> It's WebKit that does. The web content is handled by a process
> (separate from the UI process) that runs inside a bubblewrap sandbox.
> 
> In this case you need the portal in order to have access to the font
> settings:
> 
>https://github.com/flatpak/flatpak/issues/2861#issuecomment-494145504
> 
> It won't fail horribly if you don't have the portal installed, if
> you're using X11 in principle it should work fine, but under Wayland
> you won't get antialiased fonts.

IMHO, such explanations could be useful to users, who may wonder
why xdg-desktop-portal-gtk is recommended or why some features
are not available (in case the Recommends got broken, but this
is unnoticed by the user). That could be some file under the
/usr/share/doc/libwebkit2gtk-4.0-37 directory.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: use of Recommends by vlc to force users to use pipewire

[Alberto Garcia]

On Fri, May 27, 2022 at 01:03:57AM +0200, Jonas Smedegaard wrote:
> > It was actually due to a problem in Evolution that we made WebKitGTK
> > depend on xdg-desktop-portal (later downgraded to a recommendation):
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1845743
> > https://bugs.webkit.org/show_bug.cgi?id=213148
> 
> Ok, so Evolution uses sandboxing

It's WebKit that does. The web content is handled by a process
(separate from the UI process) that runs inside a bubblewrap sandbox.

In this case you need the portal in order to have access to the font
settings:

   https://github.com/flatpak/flatpak/issues/2861#issuecomment-494145504

It won't fail horribly if you don't have the portal installed, if
you're using X11 in principle it should work fine, but under Wayland
you won't get antialiased fonts.

Berto

Re: use of Recommends by vlc to force users to use pipewire

[Vincent Lefevre]

On 2022-05-26 20:08:22 +0100, Simon McVittie wrote:
> 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.

This doesn't seem to be correct. The pipewire-pulse package was not
installed on my machine (it got installed on 2021-10-26 due to some
upgrade, but the change was reverted or something like that, and it
got removed 3 days later). However, with the installation of
vlc-plugin-pipewire, VLC was automatically using pipewire, and
apparently ditto with ogg123 (via ALSA, which I had as the default).

> 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).

However, for the support of bluetooth devices, libspa-0.2-bluetooth
is needed, but it isn't even pulled when pipewire is installed!

> > 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.

Thanks for the explanations. 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. Moreover,
even with pipewire installed automatically, users should expect
regressions (see above about bluetooth devices).

Packages depend on library packages just to be able to use some
provided functions, in case they will be called. It doesn't mean
that the intent is that associated optional services will be used.

For instance, many packages (providing applications or libraries)
depend on libcups2, but this doesn't mean that the user will need
a CUPS server (or client). Ditto for libavahi-client3 and various
other libraries.

Concerning WebKitGTK, in a similar way, I think that there should
be a separation between the basic rendering library and the fully
featured web browser engine. So libwebkit2gtk-4.0-37 should not
recommend anything, and there could be a metapackage webkit2gtk-full
(or webkit2gtk-extra) that has the complete Recommends. Something
like that.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: use of Recommends by vlc to force users to use pipewire

[Jonas Smedegaard]

Quoting Alberto Garcia (2022-05-27 00:12:14)
> On Thu, May 26, 2022 at 10:09:32PM +0200, Jonas Smedegaard wrote:
> > > 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).
> > > > Ditto for the gnucash accounting software
> > > 
> > > Same dependency here: it depends on WebKitGTK.
> > 
> > To me, this highlights why libraries should rarely declare strong
> > relationship to executables:  Some consumers of WebKitGTK would want
> > to recommend xdg-desktop-portal, while others like gnucash would
> > not.
> > 
> > Email applications like astroid and balsa and evolution probably use
> > WebKitGTK for rendering html and have not use for xdg-desktop-portal
> > at all.
> 
> It was actually due to a problem in Evolution that we made WebKitGTK
> depend on xdg-desktop-portal (later downgraded to a recommendation):
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1845743
> https://bugs.webkit.org/show_bug.cgi?id=213148

Heh: I hesitated including the (to me) bloated Evolution in my list.

Ok, so Evolution uses sandboxing - which to me only says that Evolution
should recommend xdg-desktop-portal (not that the underlying library
should recommend it on behalf of all consumers of that library).

Or am I missing something?  Do you mean to say that _most_ reverse
dependencies fail horribly if xdg-desktop-portal is missing?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: use of Recommends by vlc to force users to use pipewire

[Alberto Garcia]

On Thu, May 26, 2022 at 10:09:32PM +0200, Jonas Smedegaard wrote:
> > 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).
> > > Ditto for the gnucash accounting software
> > 
> > Same dependency here: it depends on WebKitGTK.
> 
> To me, this highlights why libraries should rarely declare strong
> relationship to executables:  Some consumers of WebKitGTK would want
> to recommend xdg-desktop-portal, while others like gnucash would
> not.
> 
> Email applications like astroid and balsa and evolution probably use
> WebKitGTK for rendering html and have not use for xdg-desktop-portal
> at all.

It was actually due to a problem in Evolution that we made WebKitGTK
depend on xdg-desktop-portal (later downgraded to a recommendation):

https://bugzilla.redhat.com/show_bug.cgi?id=1845743
https://bugs.webkit.org/show_bug.cgi?id=213148

Berto

Re: use of Recommends by vlc to force users to use pipewire

[Jonas Smedegaard]

Quoting Simon McVittie (2022-05-26 21:08:22)
> On Thu, 26 May 2022 at 17:21:27 +0200, Vincent Lefevre wrote:
> > 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.

To me, this highlights why libraries should rarely declare strong
relationship to executables:  Some consumers of WebKitGTK would want to
recommend xdg-desktop-portal, while others like gnucash would not.

Email applications like astroid and balsa and evolution probably use
WebKitGTK for rendering html and have not use for xdg-desktop-portal at all.

Similar for bibledit and gnucash and bijiben and liferea.  From a quick
look, I would guess that *most* reverse depenencies of WebKitGTK make no
use of xdg-desktop-portal.

Recommending xdg-desktop-portal should be done by those applications
doing sandboxing and therefore needing it.

Oh, and thanks for yet another wonderful explanation, Simon!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: use of Recommends by vlc to force users to use pipewire

[Jérémy Lal]

Le jeu. 26 mai 2022 à 21:08, Simon McVittie  a écrit :

> 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 !

Re: use of Recommends by vlc to force users to use pipewire

[Simon McVittie]

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.

smcv

Re: use of Recommends by vlc to force users to use pipewire

[Jonas Smedegaard]

Quoting Sebastian Ramacher (2022-05-16 00:56:03)
> On 2022-05-16 00:40:25 +0200, Vincent Lefevre wrote:
> > The vlc package now uses a Recommends (vlc-plugin-pipewire) to force
> > users to use pipewire instead of pulseaudio (which broke the use of
> > VLC, but also apparently ogg123 with the alsa device). IMHO, this is
> > a bad use of Recommends. It is not up to applications to choose what
> > sound server to use, even via a meta-package like vlc.
> > 
> > Shouldn't there be something in the policy about that?
> 
> Nothing forces pipewire on you. If you don't want it, don't install it.
> It isn't a dependency.
> 
> And for the record: you get pipewire installed because libpipewire-0.3-0
> recommends it.

Package relations are directional: Applications need libraries, but
libraries rarely need applications.

libpipewire-0.3-0 should not recommend pipewire, because the library
cannot know if reverse dependencies needs it strongly or weakly.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: use of Recommends by vlc to force users to use pipewire

[Vincent Lefevre]

On 2022-05-17 08:54:59 -0400, Marvin Renich wrote:
> There is, unfortunately, a catch here.  In order for any of the
> applications that require a sound server to work, one of them must be
> installed.  For example, mpd links with libasound, libpipewire, and
> libpulse.  If each of these libs simply provides the glue to another
> package that provides the middleware and drivers, and for the reasons
> stated above they each only Suggest their middleware package, then it is
> possible for _none_ of the sound servers to be installed.

AFAIK, this kind of issue is normally solved with on ORed Recommends
(when a virtual package is not defined for that). For instance,
libaspell15 has

  Recommends: aspell-en | aspell-dictionary | aspell6a-dictionary

So, if the user already chose a solution, it won't be overridden
by the default.

Here, this could be

  Recommends: pipewire | pulseaudio

but IMHO, it is not up to libraries to do such Recommends, but
to audio applications or desktop environments, or something
done automatically at installation time where the user chooses
which kind of installation he wants? But isn't a sound system
already installed by default with a typical installation of a
desktop machine?

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'
Inst pipewire-bin (0.3.19-4 Debian:11.3/stable [amd64])
Inst pipewire (0.3.19-4 Debian:11.3/stable [amd64])

(FYI, atril is just a PDF/PS/DVI document viewer, no relation
with audio at all.)

Ditto for the gnucash accounting software:

joooj:~> apt-get install -s gnucash | grep '^Inst pipewire'
Inst pipewire-bin (0.3.19-4 Debian:11.3/stable [amd64])
Inst pipewire (0.3.19-4 Debian:11.3/stable [amd64])

> I do not fully understand the relationships between the different sound
> servers, for example I think pulseaudio can use ALSA as one of its
> backends, but do I think that they all need to be co-installable without
> interfering with the operation of each other, because some applications
> appear to only use pulseaudio and others only pipewire.  Clearly from
> the original message in this thread, installing pipewire breaks at least
> some setups when using VLC and ogg123.

Worse than that, ogg123 (when used with ALSA) remained broken after
I uninstalled pipewire (perhaps because default choices were
automatically changed in the mean time). I eventually managed to
fix the issue by randomly changing options in pavucontrol.

> This is definitely a bug, either of severity "serious" (violates
> Debian Policy definition of "Recommends") or "critical" (breaks
> other software). But I think to sort this out will require the sound
> server maintainers to come up with a way for the user specify which
> sound server to use, and then have a metapackage that forces at
> least one of them to be installed.
> 
> I think you (Vincent) are fully justified in filing a bug against
> libpipewire of severity at least "serious", however it may take more
> than just downgrading the Recommends to Suggests in order to straighten
> this out correctly.

Any comment from anyone else?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: use of Recommends by vlc to force users to use pipewire

[Marvin Renich]

* Marvin Renich  [220517 08:55]:
> I do not fully understand the relationships between the different sound
> servers, for example I think pulseaudio can use ALSA as one of its
> backends, but do I think that they all need to be co-installable without
 I do
> interfering with the operation of each other, because some applications

Re: use of Recommends by vlc to force users to use pipewire

[Marvin Renich]

* Vincent Lefevre  [220517 06:36]:
> On 2022-05-16 16:14:02 +, Bill Allombert wrote:
> > On Mon, May 16, 2022 at 12:56:03AM +0200, Sebastian Ramacher wrote:
> > > And for the record: you get pipewire installed because libpipewire-0.3-0
> > > recommends it.
> > 
> > For a similar situation, I advocated to add a apt option so that apt
> > only install Recommends of the packages on the command line, but not
> > Recommends of dependencies (and not Recommends of Recommends).
> > This would make recommends more usable but less deterministic.
> 
> So, if I understand correctly, this implies that if a package A needs
> package B and package B recommends package C, and if it happens that
> A needs C, then package A should also depend on or recommend C.
> 
> And what about upgrades? Should Recommends be checked only for
> manually installed packages?

I disagree with making Recommends non-transitive.  The problem is
incorrect use of Depends and Recommends.  This used to be a much bigger
problem; at least one large packaging group in the past had
intentionally abused Depends in metapackages because they felt too many
users had turned off automatic Recommends, and they were getting too
many bug reports about features not being available.  Turning off
automatic Recommends was (and still is, I think) common because too many
packages inflate the dependencies.  Inflating dependencies creates a
positive feedback loop, which will only end with the entire archive
using _Depends_ for everything.

The situation seems to be much better now, but it is still not as good
as it could be.

Let's analyze the Recommends in libpipewire-0.3.0.  First, the
definition of Recommends:

This declares a strong, but not absolute, dependency.

The Recommends field should list packages that would be found
together with this one in all but unusual installations.

Because pipewire, pulseaudio, and ALSA each provide sound middleware,
and the user may have a preference for one of them, a number of
applications (e.g. mpd, obs-studio, and webcamoid-plugins) link the
libraries for all three sound servers.  Somehow they each choose which
library to use at runtime.

It is clear from this that libpipewire is commonly installed in
situations where pipewire is not only not used, but actually not
_wanted_.  Using Recommends is clearly wrong in this case, both from a
practical point of view and by any reasonable interpretation of Policy.

This same analysis, when applied to other situations, is why making
Recommends non-transitive is the wrong solution to the problem; fixing
the level of dependency is the right solution.

There is, unfortunately, a catch here.  In order for any of the
applications that require a sound server to work, one of them must be
installed.  For example, mpd links with libasound, libpipewire, and
libpulse.  If each of these libs simply provides the glue to another
package that provides the middleware and drivers, and for the reasons
stated above they each only Suggest their middleware package, then it is
possible for _none_ of the sound servers to be installed.

I do not fully understand the relationships between the different sound
servers, for example I think pulseaudio can use ALSA as one of its
backends, but do I think that they all need to be co-installable without
interfering with the operation of each other, because some applications
appear to only use pulseaudio and others only pipewire.  Clearly from
the original message in this thread, installing pipewire breaks at least
some setups when using VLC and ogg123.  This is definitely a bug, either
of severity "serious" (violates Debian Policy definition of
"Recommends") or "critical" (breaks other software).  But I think to
sort this out will require the sound server maintainers to come up with
a way for the user specify which sound server to use, and then have a
metapackage that forces at least one of them to be installed.

I think you (Vincent) are fully justified in filing a bug against
libpipewire of severity at least "serious", however it may take more
than just downgrading the Recommends to Suggests in order to straighten
this out correctly.

...Marvin

Re: use of Recommends by vlc to force users to use pipewire

[Vincent Lefevre]

On 2022-05-16 16:14:02 +, Bill Allombert wrote:
> On Mon, May 16, 2022 at 12:56:03AM +0200, Sebastian Ramacher wrote:
> > And for the record: you get pipewire installed because libpipewire-0.3-0
> > recommends it.
> 
> For a similar situation, I advocated to add a apt option so that apt
> only install Recommends of the packages on the command line, but not
> Recommends of dependencies (and not Recommends of Recommends).
> This would make recommends more usable but less deterministic.

So, if I understand correctly, this implies that if a package A needs
package B and package B recommends package C, and if it happens that
A needs C, then package A should also depend on or recommend C.

And what about upgrades? Should Recommends be checked only for
manually installed packages?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: use of Recommends by vlc to force users to use pipewire

[Bill Allombert]

On Mon, May 16, 2022 at 12:56:03AM +0200, Sebastian Ramacher wrote:
> On 2022-05-16 00:40:25 +0200, Vincent Lefevre wrote:
> > The vlc package now uses a Recommends (vlc-plugin-pipewire) to force
> > users to use pipewire instead of pulseaudio (which broke the use of
> > VLC, but also apparently ogg123 with the alsa device). IMHO, this is
> > a bad use of Recommends. It is not up to applications to choose what
> > sound server to use, even via a meta-package like vlc.
> > 
> > Shouldn't there be something in the policy about that?
> 
> Nothing forces pipewire on you. If you don't want it, don't install it.
> It isn't a dependency.
> 
> And for the record: you get pipewire installed because libpipewire-0.3-0
> recommends it.

For a similar situation, I advocated to add a apt option so that apt
only install Recommends of the packages on the command line, but not
Recommends of dependencies (and not Recommends of Recommends).
This would make recommends more usable but less deterministic.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: use of Recommends by vlc to force users to use pipewire

[Vincent Lefevre]

On 2022-05-16 00:56:03 +0200, Sebastian Ramacher wrote:
> On 2022-05-16 00:40:25 +0200, Vincent Lefevre wrote:
> > The vlc package now uses a Recommends (vlc-plugin-pipewire) to force
> > users to use pipewire instead of pulseaudio (which broke the use of
> > VLC, but also apparently ogg123 with the alsa device). IMHO, this is
> > a bad use of Recommends. It is not up to applications to choose what
> > sound server to use, even via a meta-package like vlc.
> > 
> > Shouldn't there be something in the policy about that?
> 
> Nothing forces pipewire on you. If you don't want it, don't install it.

I repeat: I have *NEVER* installed pipewire manually.

> It isn't a dependency.
> 
> And for the record: you get pipewire installed because libpipewire-0.3-0
> recommends it.

Yes, but users should not be forced to go against "Recommends",
as this yields various issues.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: use of Recommends by vlc to force users to use pipewire

[Sebastian Ramacher]

On 2022-05-16 00:40:25 +0200, Vincent Lefevre wrote:
> The vlc package now uses a Recommends (vlc-plugin-pipewire) to force
> users to use pipewire instead of pulseaudio (which broke the use of
> VLC, but also apparently ogg123 with the alsa device). IMHO, this is
> a bad use of Recommends. It is not up to applications to choose what
> sound server to use, even via a meta-package like vlc.
> 
> Shouldn't there be something in the policy about that?

Nothing forces pipewire on you. If you don't want it, don't install it.
It isn't a dependency.

And for the record: you get pipewire installed because libpipewire-0.3-0
recommends it.

Cheers
-- 
Sebastian Ramacher

use of Recommends by vlc to force users to use pipewire

[Vincent Lefevre]

The vlc package now uses a Recommends (vlc-plugin-pipewire) to force
users to use pipewire instead of pulseaudio (which broke the use of
VLC, but also apparently ogg123 with the alsa device). IMHO, this is
a bad use of Recommends. It is not up to applications to choose what
sound server to use, even via a meta-package like vlc.

Shouldn't there be something in the policy about that?

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)