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
