Hi Lukas,

Regarding

> #5 implement symbols tracking for all the .so libraries shipped by kea-common,

we have been working on a solution for the symbols file of this package. As you know, dealing with C++ symbols may be tricky in some situations.

In the log4cplus case, things were quite under control due to upstream's diligence on handling the library symbols. All symbols they do desire to export are properly annotated to use compiler features to get them exposed [2].

In the isc-kea case, the upsream project does not seem to make use of any methods to avoid leaking C++ symbols. This let to the following situation:

kea-common currently exports ~11k symbols spread among 22 different shared objects. Most of these symbols are leaking symbols from boost::, std::, internal symbols, or templates.

Initially, we tried to craft a small set of filters for a version script [3], just as we did with log4cplus. However, we could not come up with a good set of generic and reliable filters in a way we could ensure that future versions of these libraries would not have symbols wrongly removed from them.

Next, we decided to ship the large symbols file, without any filtering on the exported symbols, i.e., use the ~11k symbols file.

A trial build for all architectures failed for all architectures but for amd64 (as it is expected when crafting a symbols file). While the symbols file diffs for s390x, ppc64el and arm64 were all under control (each diff would have around 120 LOC), the diffs for armhf and riscv have 15k and 12k LOC, respectively, as you can see in the isc-kea 2.2.0-5ubuntu1~ppa1 build in [4].

Moreover, this diffs do not apply cleanly at all, abruptly increasing the effort to craft and maintain the symbols file (note that there are 22 different libraries being handled in the file).

The next steps to generate the symbols file would be to generate the file separately in each supported arch, split the entries for the 22 libraries, merge the symbols for all the arches, removing duplication, and then merging everything in a single symbols file. The most concerning issue here is that this process would have to be performed in most rebuilds of this package (which seems to much, even if we automate the process).

Hence, we are wondering if providing a shlibs control file with strong dependency instead of a symbols file would be acceptable here. Note that the only reverse dependencies for kea-common and its libraries are the kea packages themselves.

For this, we would just change the d/rules to sth in the lines of

include /usr/share/dpkg/pkg-info.mk
...
override_dh_makeshlibs:
       dh_makeshlibs -pkea-common -V'kea-common (= ${DEB_VERSION})'
       dh_makeshlibs -Nkea-common

Then, we could proceed to contact kea upstream to either provide a version script with the package or to consider using the compilers visibility features for the libraries.

Thoughts?

[1] https://wiki.debian.org/UsingSymbolsFiles#C.2B-.2B-_libraries
 the ~11k symbols
[2] https://wiki.debian.org/UsingSymbolsFiles#Proper_visibility_for_C.2B-.2B-_symbols
[3] https://www.gnu.org/software/gnulib/manual/html_node/LD-Version-Scripts.html
[4] https://launchpad.net/~athos-ribeiro/+archive/ubuntu/log4cplus-symbols/+packages