Bug#934811: webrtc-audio-processing 1.0 available

[Thomas Uhle]

On Tue, 1 Feb 2022, Jonas Smedegaard wrote:

> I have continued the work of Laurent Bigonville and believe to have a
> worthy candidate targeted experimental.
>
> One potential issue remaining is a lintian warning:
>
> > W: libwebrtc-audio-processing1: package-name-doesnt-match-sonames libwebrtc-audio-coding-1-0 libwebrtc-audio-processing-1-0
>
> I guess it is harmless, but I have been wrong before about SONAME
> handling.

Well, I guess what lintian is trying to tell you is that the library name 
has changed with version 1.0.  Before the current version, it has been 
'libwebrtc_audio_processing.so.1', and now it is 
'libwebrtc-audio-processing-1.so.0'.  That is why lintian proposes to 
rename the binary package 'libwebrtc-audio-processing1' (which has been 
correct for the former library name) to 'libwebrtc-audio-processing-1-0'. 
Keeping the package name 'libwebrtc-audio-processing1' would risk to break 
any other binary packages like pulseaudio or libspa-0.2-modules because 
those binaries for the AEC module still link to 
libwebrtc_audio_processing.so.1 which is but removed during a version 
update.  By renaming the binary package, you could have both versions of 
the library installed side by side.


> Please tell if someone from the Pulseaudio team is gonna take it from
> here.  There has been quite silent on this bugreport for some time, so
> if I don't hear a response I am likely to release what I have as an NMU
> targeted experimental, with a follow-up targeted unstable (if all goes
> well, obviously), but I would prefer to not take over maintenance of
> this package.

Pushing the current version in experimental to unstable as-is would break 
pulseaudio, libspa-0.2-modules and gstreamer1.0-plugins-bad at least and 
scheduling a binNMU for these packages would not help as they are not yet 
ready for version 1.0 of webrtc-audio-processing.  It seems that the 
effort for PipeWire would be less than for PulseAudio, but at this very 
moment none of these would compile out of the box.

It might even make sense to consider to also rename 
'libwebrtc-audio-processing-dev' to 'libwebrtc-audio-processing-1-dev' if 
you want to push the new version to unstable because the path to the 
header files has changed as well as the name of the data file for 
pkg-config.  This way you could also install the development files from 
both versions side by side which might help the other projects to migrate 
to the new webrtc-audio-processing version at their own pace.

Last but not least, the binary package libwebrtc-audio-processing-dev 
needs to depend on libabsl-dev because some of the header files include 
header files from Abseil.

Best regards,

Thomas Uhle