Re: pipewire: update to 0.3.17

[ahesford <ahesford@users.noreply.github.com>]

[-- Attachment #1: Type: text/plain, Size: 2203 bytes --]

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/pull/26822#issuecomment-738837331

Comment:
> The only thing missed is that both pipewire and pipewire-pulse server need to be run as user service, and this with runit is not that simple to have

@gspe The `pipewire-jack-plugin` is still unsuitable. First, `conflicts` are inappropriate in your proposal because there are no inherent conflicts with `jack`. Second, `ld.so.conf.d` is not recognized by musl, so this misses half of the archs supported by Void. (While musl does allow custom linker search paths, it does so through a file and isn't really compatible with packaging.) The right way to do this is probably declaring an actual conflict with `jack` (or, more likely, `libjack`) and installing the compatibility library or a symlink where `libjack` puts it. This would also require a `provides` mechanism so that XBPS won't attempt to force `libjack` to be installed when the pipewire conflict is currently installed.

Coalescing the `libspa*` packages is fine as long as the grouping makes sense. To the extent that these plugins are truly optional, they should remain separate to allow users to omit those pieces when desired. The "core" plugins can still be rolled into `libpipewire`, or else `libpipewire` can depend on the core `libspa*` packages if there is an argument for greater control (this allows users to `ignorepkg` to exclude some of the core packages if they really want, which is a better mechanism than `noextract`, which would be necessary to exclude plugins in the `libpipewire` package). Note that `libpipewire` should declare `replaces` for every `libspa*` package it assimilates, or else XBPS will not be able to manage a smooth transition.

The need for per-user runs is not a problem that Void attempts to solve, nor should it. There are many ways that users can ensure the server is launched when they need it, including our recommended [per-user service mechanism](https://docs.voidlinux.org/config/services/user-services.html) or launching from some X or Wayland startup script. When users adopt Void, they assume responsibility for solving this kind of problem.