[RFC] pipewire: split p-m-s into separate package, do not autostart session manager by default

[CameronNemo]

This proposes major changes to the handling of PipeWire session managers.

The PipeWire developers recommend the use of WirePlumber, but this is inconvenient with the current pipewire package.
In this PR I aim to improve the UX of void pipewire users by:

• splitting pipewire-media-session into a standalone package
• adding conflicts between pipewire-media-session and wireplumber

The most immediate implication is that Void users who are using the default configuration (pipewire-media-session) and upgrade to this new pipewire version without further intervention will have their setups broken. There will be no session manager running and pipewire will not function correctly. A news post will likely be needed to ensure that users are well informed of how to proceed.

Testing the changes

• I tested the changes in this PR: YES

New package

• This new package conforms to the quality requirements: YES

[paper42]

How well does this work if someone has their own /etc/pipewire/pipewire.conf with wireplumber in context.exec there? Does this PR make it run both wireplumber and pipewire-media-session?

[CameronNemo]

Yeah I think it would.

I am planning to send a PR for the docs repository, but the Void recommended method of running wireplumber would be to add a drop in with the same name that masks the default pipewire-media-session one.

I am waiting on the next pipewire release for this to work correctly, though. The whole masking part does not happen without some changes to the config handling that were made a short time ago.

[ericonr]

How wonky do things get with both wireplumber and p-m-s running?

[CameronNemo]

Looks like pipewire exits from what I can tell.

[W][00091.300132] ms.core      | [ media-session.c: 2211 core_error()] error id:29 seq:2024 res:-16 (Device or resource busy): Start error: Dispositivo o recurso ocupado

[CameronNemo]

Any further comments on this? Using wireplumber on Void was never documented or particularly convenient. This pair of PRs would change that situation.

[Duncaen]

I'm unsure about changing the config file setup, this is going to break peoples config and there is going to be a big breaking change of wireplumber configuration in the near future.

I think I would rather just update pipewire now and then reserve a better configuration setup for when wireplumber is to change compatibility.

Another thing is that media-session is basically abandoned and broken so actually switching to wireplumber is something that would also be a good breaking point.

[CameronNemo]

umm. tbh I am really not following your thought process there. p-m-s is broken/abandoned, so continue to ship it by default and make it really inconvenient and hacky to use wireplumber?? I can shift the default to wireplumber in this PR to just get that break over with. I know the wireplumber config will change, but this PR does not touch wireplumber configs. Do most users need to adjust the wireplumber config? On both my computers it just worked OOTB.

[Duncaen]

umm. tbh I am really not following your thought process there. p-m-s is broken/abandoned, so continue to ship it by default and make it really inconvenient and hacky to use wireplumber??

We are only in this situation because we diverted from the default configuration. Adding the new mechanism diverts more and will introduce issues for anyone who already just masked the default configuration.

There will be more breaking changes in the future as we should switch to wireplumber by default and we can't just simply switch over because it introduces a build cycle.

I don't think there is a reason to rush a change that breaks the configuration by combining it with the pipewire update.

It would probably be cleaner to revert back to the default configuration that does not start a session manager and then document that users can add a drop in configuration file, like shipped in this PR to start a session manager through pipewire.

[CameronNemo]

I don't think there is a reason to rush a change that breaks the configuration by combining it with the pipewire update.

Ok that was not really my intention to bundle, just the way I wanted to do it needed changes upstream so I had to wait for the update.

It would probably be cleaner to revert back to the default configuration that does not start a session manager and then document that users can add a drop in configuration file, like shipped in this PR to start a session manager through pipewire.

Yeah that would work fine for me. I use a service manager to supervise wireplumber. But that way would break everyone rather than just the subset who overrode the XBPS-provided default config to use wireplumber.

[CameronNemo]

Driven by discussion in IRC, my current plan is to:

• split pipewire-media-session into a subpackage and add an XDG autostart file for users to enable
• add XDG autostart file to wireplumber package and add conflicts for pipewire-media-session
• document the above in pipewire documentation section, including:
  • need to install one and only one session manager
  • how to enable the session manager (XDG autostart vs. in config)

I will likely need to wait until October until I have time to refresh this PR. In the meantime please do not hesitate to separately update pipewire, I will need to rebase my branch regardless so it should be no issue.

[leahneukirchen]

split pipewire-media-session into a subpackage

I just ran into this issue, 👍 for me on this approach.

[JamiKettunen]

I've also been using wireplumber with some manual config trickery, not forcing pipewire-media-session on users by default would be good imo. Also this probably should be rebased and the update commit dropped so this PR can focus on the main issue at hand ^^

Keep in mind 4c572dc added configure_args+=" -Dsession-managers=media-session" which likely has to be touched here.

[CameronNemo]

@JamiKettunen thanks for the notes

[CameronNemo]

I have updated this branch and would appreciate review and additional testers.

[CameronNemo]

I have updated this branch and would appreciate review and additional testers.

[motorto]

Tested this PR and everything works as expected (used the pipewire-media-session), so for me this looks good.

[oreo639]

pipewire-media-session 0.4.2 is now out: https://gitlab.freedesktop.org/pipewire/media-session/-/releases
You should probably add the patches listed here: https://gitlab.freedesktop.org/pipewire/pipewire/-/releases

The wireplumber.desktop solution doesn't really work since in order for wireplumber to run pipewire must be running, unlike pipewire-pulse which can still run even if pipewire isn't running.
I tried wireplumber with the content.exec solution and that works great.

Would it make sense to provide the content.exec configs in the wireplumber/p-m-s packages themselves?

Aside from that 👍 from me.

[CameronNemo]

The wireplumber.desktop solution doesn't really work since in order for wireplumber to run pipewire must be running, unlike pipewire-pulse which can still run even if pipewire isn't running.

@paper42 I added this on your suggestion... do you have any comments here? I agree with oreo here that the context.exec methodology is a more surefire way to run the session manager.

[ahesford]

It is pretty clear that upstream does not want people running p-m-s anymore:

https://gitlab.freedesktop.org/pipewire/media-session/-/releases/0.4.2

I don't think p-m-s should be split into a subpackage; it should just be dropped with the (next) release of pipewire. At the very least, this means we should probably tack on an install message now to warn people that this will happen.

Wireplumber shouldn't depend on pipewire; in fact, the dependency should be the other way around when p-m-s is no longer an option (unless we have an alternative session manager packaged). Having the proper dependency relationship should minimize the pain of transition for users with the default configuration, but it creates a build cycle that we will have to break. Options include:

• Renaming pipewire to something like pipewire-tools or pipewire-utils and adding a standalone pipewire meta-package that pulls in pipewire-tools as well as wireplumber. This has the advantage that we don't really have to worry about syncing the build process between two artificially split packages. In fact, the meta can just get a dated version that we only bump when we need to.
• Alternatively, libpipewire and pipewire-devel could be split into a standalone package so that wireplumber can pull them in without the rest. This kind of sucks because we'll be forced to keep two packages synchronized.
• Coming up with some way to build wireplumber without the pipewire-devel dependency. Meh.

[CameronNemo]

@ahesford no offense but I dislike all three options listed. I don't think telling users to install wireplumber instead of pipewire is too much to ask. Many users won't need to manually install either; it can be pulled in by other meta packages like gnome/kde ones. The only package name which I would be happy with for a theoretical pipewire+wireplumber meta package is base-pipewire.

[ahesford]

All options are undesirable, sure; but they are not all equally undesirable.

As it stands, your proposal ships a pipewire package that will not function without adding additional packages. GNOME and KDE may pull in wireplumber; other people (like me) have already manually installed wireplumber; still others may only have pipewire installed, and not having pipewire pull in a session manager means that those users upgrading (or pulling pipewire for the first time) will find that the default configuration is broken.

You can make the argument that new users should read the docs, and we should have documentation that tells people "to use pipewire, install pipewire and wireplumber". However, that doesn't change the fact that dropping pipewire-media-session will pull the rug out from all users already using pipewire that aren't also using wireplumber (directly or transitively). That's a crappy experience. No matter what we do, we might cause problems for people with custom configs, but that is somewhat unavoiable and less crappy because those people should be expected to know how their configuration deviates and diagnose when it breaks.

If you concede that something should exist as a convenience to pull in both pipewire and wireplumber, making pipewire the meta-package is necessary to ensure a smooth upgrade path. Keeping pipewire as is and making a new pipewire-base or something along those lines means upgrading users will not see the new package structure.

[CameronNemo]

I don't think I have the bandwidth for this. I've already gone through multiple iterations over the course of months, and have been repolocking pipewire and wireplumber during that time. Someone else is welcome to pick this up.

[ahesford]

Taking this up in #41846