Comment 4 for bug 1977551

#1 & #2 -> OK!
#4 & #5 -> Those are only recommended TODOs and won't block the MIR, thanks for pestering the DM about it, though. Those will most probably come back to us eventually, but it's fine for now!

#3: Thanks, I wasn't aware of pkgkde-symbolshelper!
So at least they are using some advanced tools to track their (C++) symbols.
The problem I see with this is that during testing it does not detect an API/ABI breakage, that I introduced on purpose. E.g. if I rename the "lerc_encodeForVersion" API to "lerc_encodeForVersionX", dpkg-buildpackage still passes the build, displaying a warning at least:
dh_makeshlibs -- -v3.0 -c0
dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below
dpkg-gensymbols: warning: debian/liblerc3/DEBIAN/symbols doesn't match completely debian/liblerc3.symbols
--- debian/liblerc3.symbols (liblerc3_3.0_amd64)
+++ dpkg-gensymbolsaQREWf 2022-06-21 15:22:43.440908065 +0000
@@ -382,4 +382,5 @@
  lerc_decodeToDouble@Base 3.0
  lerc_encode@Base 3.0
  lerc_encodeForVersion@Base 3.0
+ lerc_encodeForVersionX@Base 3.0
  lerc_getBlobInfo@Base 3.0

But "lerc_encodeForVersion" is still there as a symbol, even though I removed/renamed it from the public header and implementation and the build doesn't fail (which is what I would expect in such case)... So I wonder if those tools are being used correctly.

Re-reading the MIR rules, we only ask for "symbols tracking is in place", not that it needs to fail the build... so this could be a tentative MIR team ACK.

But let me check back with the other MIR team members (while waiting for security-review anyway), just to be sure that this is what was intended here.

PS: C++ libraries seem to be a special case anyway, here's an interesting read:
https://wiki.debian.org/UsingSymbolsFiles#C.2B-.2B-_libraries