It seems main pulseaudio libs got a soname bump and, then, some packages need to be rebuilt after updating >>> package: media-sound/pulseaudio-13.0 * - /usr/lib64/pulseaudio/libpulsecommon-12.2.so * used by /usr/lib64/pulse-12.2/modules/libbluez5-util.so (media-sound/pulseaudio-modules-bt-9999) * used by /usr/lib64/pulse-12.2/modules/module-bluetooth-policy.so (media-sound/pulseaudio-modules-bt-9999) * used by /usr/lib64/pulse-12.2/modules/module-bluez5-device.so (media-sound/pulseaudio-modules-bt-9999) * used by /usr/lib64/pulse-12.2/modules/module-bluez5-discover.so (media-sound/pulseaudio-modules-bt-9999) * - /usr/lib64/pulseaudio/libpulsecore-12.2.so * used by /usr/lib64/pulse-12.2/modules/libbluez5-util.so (media-sound/pulseaudio-modules-bt-9999) * used by /usr/lib64/pulse-12.2/modules/module-bluetooth-discover.so (media-sound/pulseaudio-modules-bt-9999) * used by /usr/lib64/pulse-12.2/modules/module-bluetooth-policy.so (media-sound/pulseaudio-modules-bt-9999) * used by 2 other files I would simply use "13" as subslot and make it follow soname versions
I disagree. Only private libraries got a bump, but pulseaudio-modules-bt (a 9999 at that) happens to be linking to them, because it's an out of tree module that doesn't even have any keyworded versions in the tree. I know of no other such packages that would be affected.
These private libraries carry even the _full_ version number, so 13.1 changes it again, etc. But that's not really even the biggest problem for this pulseaudio-modules-bt monstrosity - it installs things to the version specific modules dir as well, so without a rebuild pulseaudio won't even load them. But my point is - I don't see a value in providing a subslot and all the involved overhead just to fix 1 live ebuild that ideally wouldn't even exist.
Well, it's live ebuild because current downstream maintainer only packages that one, but its upstream provides regular versions too. Also, if only few packages will consume it, it won't be a huge overhead (it will be a bit like poppler consumers... that not all need to add the subslot dep... in this case for now this package will need it and, probably, any package that could rely on pulseaudio-libs in the future)
Regarding if the module shouldn't ideally exist... last time I checked upstream bug I got into the conclusion that the plugins won't get merged soon... also looking at the pace pulseaudio upstream have for this things... I guess the package will still be around for months (or years)
Other option could be have a virtual package for "pulseaudio-private-libs" (or similar name) to bump that subslot there and keep main pulseaudio package as-is Maybe that could fit all the scenarios
Lets think about it a bit more; if you have links discussing potential inclusion of this upstream, would be helpful
Sure, I think I miss one more reference I saw in the past... but I couldn't find it :S https://github.com/EHfive/pulseaudio-modules-bt/wiki#are-there-any-plans-to-upstream-this-into-pulseaudio https://github.com/EHfive/pulseaudio-modules-bt/issues/1#issuecomment-446947961 https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/36 https://eischmann.wordpress.com/2019/02/11/better-bluetooth-sound-quality-on-linux/
You could consider dropping pulseaudio-modules-bt in favour for SBC XQ: http://soundexpert.org/articles/-/blogs/audio-quality-of-sbc-xq-bluetooth-audio-codec There is a very non intrusive patch for PA 13 and I think the author of SBC XQ think XQ replaces the need of other codecs.
Since pulseaudio-modules-bt is considered deprecated per author at https://github.com/EHfive/pulseaudio-modules-bt/issues/154 I think this bug can be closed with no action needed?
I think this can be closed now, both SBC XQ and gstreamer-based codecs are now available with pulseaudio-15.0-r3
(In reply to Igor V. Kovalenko from comment #10) > I think this can be closed now, both SBC XQ and gstreamer-based codecs are > now available with pulseaudio-15.0-r3 Yeah, obsolete at this point I think.
