Clarification on coexistence of wireplumber and pipewire-media-session

While testing out WirePlumber it become clear the way distros packaged it along with PipeWire itself could lead to some issues. I thought it would be best to have upstream clarification on what distros should do before opening issues for each package.

Should the Arch PipeWire package assume to always enable pipewire-media-session as here? While trying out WirePlumber with EasyEffects on Arch there was trouble with the pipewire-media-session service not being disabled since the pipewire package assumes the user will always want pipewire-media-session enabled.

Should distro packagers set wireplumber and pipewire-media-session to conflict, similarly to pipewire and pipewire-pulse? Fedora 35 conflicts between the two packages. Furthermore on Arch pipewire-media-session is a hard dependency of many pipewire packages, so effectively one must have it installed.

changed the description

fwiw, I did the Fedora packaging for wireplumber and the required changes to the pipewire package.

Wireplumber (WP) and pipewire-media-session (MS) are two components that serve the same space, but only one can run at any time. You can have both installed at the same time of course but only one can run at a time.

Historically, pipewire started MS directly as part of the config file but pipewire should not care about which session-manager is running. Better is to have a systemd service file, so that once you install a session-manager you can start that one automatically.

From that, a simple packaging decisions follows: if you have service files for both MS and WP installed, you'll get a race condition - whichever binds first will win. The best way to fix this is to ensure only one can be installed at a time.

In Fedora, what was needed was first to split out MS into a separate subpackage and have that activate via the service file, then package WP and make the two conflict. Plus change to have pipewire pick WP over MS if you just dnf install pipewire so the dependencies are right. There shouldn't really be any packages relying on MS directly, either they need pipewire or any pipewire-session-manager. In Fedora, WP and MS don't conflict directly, they just both provide the same virtual pipewire-session-manager package.

An alternative approach is to have an intermediate systemd service, like pipewire-session-manager.service that alternatively points to either WP or MS. Fedora used to have something like this a decade ago for display-manager.service but this has since been changed into an Alias. I tried the alias thing with pipewire in Fedora but couldn't get it to work because the conditions are different to a display manager. If you can figure that out, I'd probably switch Fedora to use that too so we can have both installed.

Thanks for the insight!

For what it’s worth on Fedora being able to install both packages at once has a nice side effect. It would make it possible to actually switch to pipewire-media-session on OSTree based Fedora (Silverblue). As far as I’ve seen there’s no equivalent to dnf swap with rpm-ostree, so on 35 Silverblue you’re kinda stuck with wireplumber (unless you want to go out of your way to hack pipewire-media-session in somehow).

So I opened an issue for rpm-ostree so that behaviour can be improved.

Thanks! I'm trying to come up with a way to decouple wireplumber from wireplumber.service in the packaging, but... it's hard. The 99% case is of course someone wanting wireplumber installed also wanting it to run then.

The best I can think of right now is to move wireplumber-the-process into a wireplumber-daemon.rpm subpackage. That package is Requires by wireplumber.rpm (which is now basically just the service files). Then, when you install wireplumber.rpm, it installs the service files and wireplumber-daemon. Which - on disk - is what we have now. Then you could install wireplumber-daemon separately - though realistically this is quite niche too because you'd have to then write your own service files for it to work. So I'm not sure it's really a useful solution.

In the end, it looks unsolvable. You have two packages doing the same thing, each should work immediately if installed and where both are installed it should pick what the user prefers. All that without user interaction, so...

Note that the service files nowadays conflict with each other. So systemd will start one or the other, but if both are enabled it's possibly undefined which one will get started.

It is useful to have both installed, however. At least for the close future while users transition from one to the other. This way, users can swap between session managers and test possible regressions.

Technically, both can even run at the same time, as long as they service different modules. Ex, media-session could load alsa devices while wireplumber implements the policy, or vice versa... But things may get hairy there, so I wouldn't recommend anyone to do that.

It is also possible to actively use media-session and run a few scripts and/or tools (wpexec / wpctl) from the wireplumber package. This is fully supported.

So, I would recommend that distributions do not make the two conflict each other.

Note that the service files nowadays conflict with each other.

This is the point. They conflict, but the packages on Arch are not in conflict.

Besides, there's no way to disable pipewire-media-session on Arch, neither I can install wireplumber individually because pipewire-alsa/pulse/jack packages have pipewire-media-session as dependency.

https://bugs.archlinux.org/task/72219

Sorry about my last comment (deleted now), it made no sense. I did not read your description very well before replying.

I am also confused about this problem, tbh. While I recommend that the two services do not conflict with each other so that they are swappable at runtime, I also understand that from a packaging perspective it is hard to make this work if both services end up being enabled.

The question is, what can we do upstream to fix this?

The question is, what can we do upstream to fix this?

Something that would help users is some sort of warning message if WP is started when media-session is already running. Not sure how you'd do that though.

It's not super hard. We can look in the Client objects for a client that's called "media-session".

I implemented this now in !223 (merged), but what I see in practice is that because wireplumber.service conflicts pipewire-media-session.service, if you try to start wireplumber.service while pipewire-media-session.service is active, the latter will be stopped first.

It helps, though, in case pipewire-media-session is executed from pipewire.conf or by other means.

mentioned in commit 2bc99959

mentioned in merge request !223 (merged)

So, looking into this a bit further and after consulting with the debian packagers too, I think there is not much problem really in a systemd-based environment...

In systemd:

• pipewire-media-session.service is BoundBy pipewire.service
• wireplumber.service is BoundBy pipewire.service
• wireplumber.service Conflicts pipewire-media-session.service

When all these units are enabled, according to the documentation for Conflicts, we fall into the "latter case" at the end:

If unit A that conflicts with unit B is scheduled to be started at the same time as B, the transaction will either fail (in case both are required parts of the transaction) or be modified to be fixed (in case one or both jobs are not a required part of the transaction). In the latter case, the job that is not required will be removed, or in case both are not required, the unit that conflicts will be started and the unit that is conflicted is stopped.

... and therefore, only wireplumber.service is started, even though pipewire-media-session.service is also enabled. This means that when wireplumber is installed, it will always be preferred over media-session, unless the user explicitly disables it.

Minor addition here, with pipewire!970 (merged) merged, the Alias=pipewire-session-mnager.service can be provided by both wireplumber and media-session. When enabling the service it'll error out:

$ systemctl --user enable pipewire-media-session.service
Failed to enable unit: File /home/whot/.config/systemd/user/pipewire-session-manager.service already exists and is a symlink to /home/whot/.config/systemd/user/wireplumber.service.

This would make the Conflicts mostly obsolete, I think.

So now if pms is installed and we install wireplumber on top, then wireplumber will not be enabled and pms will stay enabled, right?

correct, install order doesn't matter, just which one is enabled first. You can have both installed.

I added this in wireplumber today (post 0.4.3) but I am not very happy with that approach, tbh. And I just got feedback from the debian packagers saying that they will have to revert it in debian because if you have p-m-s installed and then you try to install wireplumber, the post-install script (which enables the service) will fail.

hmm. I'm trying to think what the packaging solution to this one would be. Maybe a wireplumber-process subpackage that contains the actual binary. So we'd have wireplumber which Requires: wireplumber-process and Provides: pipewire-session-manager together with the service files.

So the package tree is

• wireplumber.spec
  • wireplumber.rpm
    • Installs + enables wireplumber.service
    • Provides: pipewire-media-session
    • Requires: wireplumber-process
  • wireplumber-process.rpm
    • Installs /usr/bin/wireplumber
    • Requires: wireplumber-libs
  • wireplumber-.... other subpackages for libs, tools, etc.

If you install wireplumber, it'll install and enable everything as before. If you just install wireplumber-process you have wireplumber but not the systemd service files.

Mirror that package split for pipewire-media-session and you we can now have both installed individually but only one can be enabled as session manager by default. The Conflicts: between WP and PMS work as before.

I think you could even have the service files installed as part of the -process package and have only the enabling logic as part of the parent package but that's going past my knowledge a bit.

Not sure about the -process name, but that probably relies on the various distro packaging guidelines anyway.

This sort of split is quite common with daemons in debian and usually the -process package that you are thinking of is suffixed with -bin.

However, I don't fully understand which problem you are trying to solve here? I can see 3 ways to package:

First method

Available packages:

• pipewire (with: Requires: (wireplumber or pipewire-media-session))
• pipewire-... (libs, plugins, anything you like to split)
• pipewire-media-session (with binaries and .service files)
• wireplumber (with binaries and .service files)
• wireplumber-...

Assuming that wireplumber is installed by default in the distribution, if a user wants to install p-m-s, she can install pipewire-media-session; this enables the pipewire-media-session.service unit, so now BOTH are enabled. Effectively, wireplumber is still executed and p-m-s is not.

To enable p-m-s, an additional systemctl --user disable wireplumber is needed. To switch back to wireplumber, systemctl --user enable wireplumber.

Second method

Available packages:

• pipewire (with: Requires: (wireplumber or pipewire-media-session))
• pipewire-... (libs, plugins, anything you like to split)
• pipewire-media-session (with .service files)
• pipewire-media-session-bin (with binaries)
• wireplumber (with .service files)
• wireplumber-bin (with binaries)
• wireplumber-...

Now again, assuming that wireplumber is installed by default and the user wants to install p-m-s, she has to do:

• <package-manager> install pipewire-media-session-bin (because pipewire-media-session will conflict and remove wireplumber?)
• systemctl --user disable wireplumber
• write a custom .service file or edit pipewire.conf to add pipewire-media-session in the exec section
• ...

OR maybe just

• <package-manager> install pipewire-media-session
• ... but at this point wireplumber will be removed, so to switch back you have to use the package manager again and therefore the -bin split serves no purpose

Third method

Available packages:

• pipewire (with: Requires: pipewire-session-manager)
• pipewire-... (libs, plugins, anything you like to split)
• pipewire-media-session (with binaries and .service files, Provides: pipewire-session-manager / Conflicts: wireplumber)
• wireplumber (with binaries and .service files, Provides: pipewire-session-manager / Conflicts: pipewire-media-session)
• wireplumber-...

So now to switch you have to use the package manager exclusively:

• <package-manager> install pipewire-media-session

This is the current approach in fedora, if I am not mistaken.

I kind of prefer the 1st method and then the 3rd method. The 1st method does not solve the problem of what to do if someone else comes up with yet another session manager, but at least it enables easy switching without installing & removing packages. It may only be a bit "strange" that installing p-m-s does not automatically enable it, but it is a very simple step that can be documented, unlike figuring out custom ways to start p-m-s in the 2nd method.

However, I don't fully understand which problem you are trying to solve here?

Being able to install both but only have one enabled (and have this work with the package management). Note that I'm trying to fix this, mostly because I thought that's what you ere trying to achieve :) But it's not going to be something we'll actively use, Fedora at least will just keep the two packages in conflict, so solving this is not really necessary for us at least. So if we've been talking past each other and neither of us really needs this, then the current situation should be good enough?

And yes, the third approach is what we have in Fedora atm.

mentioned in commit 1b48e068

I added this in wireplumber today (post 0.4.3) but I am not very happy with that approach, tbh. And I just got feedback from the debian packagers saying that they will have to revert it in debian because if you have p-m-s installed and then you try to install wireplumber, the post-install script (which enables the service) will fail.

And that has happened https://bugs.debian.org/997818

I guess I cannot only revert the commit, otherwise I will have other issue?

you'd be more likely to bump into the startup race condition again, see pipewire#1553.

Having said that, in this case it sounds something else is wrong - if media-session was removed how comes the symlink for its unit file is still present?

I guess the safe way to go forward is to make the two session managers conflict each other, i.e. follow the 3rd method described above.

added type::discussion label