#1029648 gnome-core 1:43+1 not installable with Pulseaudio

Package:
gnome-core
Source:
gnome-core
Description:
GNOME Desktop Environment -- essential components
Submitter:
Rann Bar-On
Date:
2023-01-27 09:27:05 UTC
Severity:
normal
#1029648#5
Date:
2023-01-25 20:10:52 UTC
From:
To:
Dear Maintainer,

gnome-core 43+1 depends on pipewire-audio, which conflicts with pulseaudio, making gnome-core uninstallable with pulseaudio. I think this is a probem!

Previous version of gnome-core (42+8) depended on pipewire-pulse instead.

This might be a pipewire dependency bug, I'm not sure.

#1029648#10
Date:
2023-01-25 21:12:54 UTC
From:
To:
it is intentional that users upgrading from Debian 11 to 12 should usually
get PulseAudio replaced by Pipewire during that upgrade (see #1020249).

It continues to be possible to run GNOME without installing gnome-core,
by installing gnome-session (which is the minimal GNOME session) and
whatever applications you want to run: for example, you could install
all of the dependencies of gnome-core except for pipewire-audio if that's
what you want, and that would be a valid way to configure a system.

I don't know whether it's intentional that it is no longer possible to
install gnome-core and pulseaudio together.

Pipewire maintainers: do you have an opinion on whether gnome-core should
return to depending on the individual dependencies of pipewire-audio,
rather than on the metapackage?

I'm not sure that I understand why pipewire-alsa and pipewire-audio need
to conflict with pulseaudio. Would it be sufficient to rename
/etc/alsa/conf.d/99-pipewire-default.conf to sort later than 99-pulse.conf,
or ask the pulseaudio maintainers to rename /etc/alsa/conf.d/99-pulse.conf
to sort slightly earlier? That would restore the older behaviour in which
installing both pulseaudio and the equivalent of pipewire-audio is possible,
and Pipewire "wins"?

Please clarify why this is a problem?

If there are reasons why you need to continue to use pulseaudio instead
of pipewire-pulse's implementation of a PulseAudio-compatible audio server,
please report them as bugs or feature requests in pipewire-pulse.

Did you previously have pipewire-pulse installed? If yes, how did you
arrange to avoid it taking precedence over pulseaudio?

(If the answer is that you were previously using pipewire-pulse as your
audio service, you were no longer running pulseaudio, and you hadn't
noticed any difference, then that is pipewire-pulse working as intended!)

I can see that requiring apt to figure out that it can remove pulseaudio
during upgrades might be problematic, since apt is often reluctant to
remove packages, and for that reason it might be better if we could find
a solution where leaving pulseaudio installed and inactive is possible.

Thanks,
    smcv

#1029648#15
Date:
2023-01-25 21:27:29 UTC
From:
To:
Ah! I was not aware of this.
Given the above, my opinion has changed.
This is exactly what happened! Nice job making me completely oblivious
to this change!
Maybe. I prefer cleaning up packages, so if something is inactive by
necessity, I think it should be removed.

#1029648#20
Date:
2023-01-27 09:24:42 UTC
From:
To:
Hello,

Le mer. 25 janv. 2023 à 22:13, Simon McVittie <smcv@debian.org> a écrit :

I intentionally marked pipewire-audio in conflict with pulseaudio even if there
is no technical reason for that (here I have both pulseaudio and pipewire-pulse
installed without any issue). The reason of this metapackage and its conflict
with pulseaudio is because for different reasons, users complained and filled
bugs about broken configs. The origins of these broken configs are differents
and not related to the pipewire packages. For example, it could be because they
didn't install the recommended packages (wireplumber without pipewire-pulse), or
because some packages where pinned leading to a non-functional combination of
packages. Some others followed outdated guides from random websites to switch
from pulseaudio to pipewire with as result weird conflicts with pulseaudio.
The aim of this package is to avoid common users mistakes leading to no audio.
I am annoyed for them since pipewire-pulse just works but because I have limited
time, I cannot figure what they did wrong for all of them.

I don't have a strong opinion whether gnome-core should depend on pipewire-audio
or on individual dependencies. If they follow the recommendation an upgrade from
Bullseye to Bookworm without having to conflict on pulseaudio will work
correctly. So, maybe would be better to have gnome-core not depending on
pipewire-audio to not hurt users who still want to use pulseausio leaving
optional pipewire-audio (and its conflict with pulseaudio). After all, users
complaining about a pkg conflicts between pipewire and pulseaudio had no real
reason (excepted [1]) to keep both installed just because I guess they were a
bit prudent about this transition.

[1] https://bugs.debian.org/1029377#20

Yes, that is correct. It's not implemented just because nobody asked for it.

We are lacking pedagogy on that. Not sure how we can communicate more on the
pulseaudio to pipewire transition. At least, I will have to refresh the Debian
pipewire wiki page before the release of Bookworm.

This is solved by the (optional?) pipewire-audio package which will ensure that
pulseaudio is removed.

Best regards,
Dylan