Symbols for Python3 based builds

[Matthias Klose]

Hi,

looking again at building Samba using Python3 for Ubuntu to get Python2 finally
removed from our desktop images.  Looking at the Fedora packaging it seems that
a combination of

  samba_version 4.10.0
  talloc_version 2.1.15
  tdb_version 1.3.17
  tevent_version 0.9.38
  ldb_version 1.5.2

is built.  However the Fedora packaging doesn't have any checks for symbols in
shared libraries, and doesn't see what is seen when you use the Debian/Ubuntu
packaging which is checking that you don't have any symbol mismatches without
changing the soname.

Starting with the talloc 2.1.15 tarball, I see

python2.7 based build:

libpytalloc-util.so.2 #PACKAGE# #MINVER#
 PYTALLOC_UTIL_2.0.6 at PYTALLOC_UTIL_2.0.6 2.0.6
 [...]

python3.7 based build:

libpytalloc-util.cpython-37m-x86-64-linux-gnu.so.2 python3-talloc #MINVER#
 PYTALLOC_UTIL.CPYTHON_37M_X86_64_LINUX_GNU_2.1.15 at PYTALLOC_UTIL.CPYTHON_37M_X86_64_LINUX_GNU_2.1.15 2.1.15
 PYTALLOC_UTIL.PY3_2.1.10 at PYTALLOC_UTIL.PY3_2.1.10 2.1.15
[...]

so the symbol names add normally just a '.PY3' suffix, but the extra symbol and
version seems to be unwanted.  There again the specific major Python version is
encoded (37M), and also the architecture is both encoded in a symbol name and
version, which makes the library have different symbols on different
architectures. I have never seen such an explicit encoding in other shared
libraries. It looks to me that this comes from

  python3-config --extension-suffix

This symbol versioning propagates to tdb, ldb, and other libraries.  Maybe I'm
missing some thing in the configuration of the packages?  Otoh, based on
discussions with Andrew Bartlet at LinuxConfAU 2018, the intention was not to
have any encoding of a specific python version or architecture. Thoughts?

Matthias