[Python-modules-team] Bug#886291: src:pycryptodome: Building both pycryptodome and pycryptodomex: duplicate dbgsym package

[Simon McVittie]

On Wed, 15 Aug 2018 at 14:30:17 +0200, Alexis Murzeau wrote:
> I'm trying to find a way to build 2 times a python source package to
> generate 2 binary packages which both contains .so libs and this cause 2
>  duplicated dbgsym packages with same files.

The Linux kernel had this problem recently, and it seems to have been
solved by adding the version number as a "salt" that will affect
build IDs:
https://sources.debian.org/src/linux/4.17.14-1/debian/patches/features/all/kbuild-add-build-salt-to-the-kernel-and-modules.patch/

Perhaps you could do similar by including a string in these shared
libraries (a new, unused global variable or something) that mentions
either Crypto or Cryptodome, as appropriate for the build, similar to
the tricks that used to be used to include a RCS/CVS/svn "$Id$" string
in binaries? (In the kernel implementation it's an ELF note, but a global
constant string would be equally valid, as long as it doesn't get deleted
by optimization.)

Or you could have a python{,3}-pycryptodome-common package containing the
parts that are the same for both namespaces, if their size is significant;
or you could make python{,3}-pycryptodome (the one that overrides the
standard library's Crypto module) depend on python{,3}-pycryptodomex in
order to share its copies of the parts that end up the same.

The kernel patch refers to something in RPM that incorporates the package
name and version in the build ID, but this probably wouldn't work within
a single source package.

> Maybe only some .so libraries change between both. I don't think it's
> safe to assume upstream won't make a change causing some of these .so to
> change between pycryptodome and pycrytodomex.

If you decide to share the libraries that are the same despite this,
please add checks to the build to compare them, so that the build will
fail if they start to be different. That would catch those upstream
changes.

> I think the best would be to have only on dbgsym package for both
> python{,3}-pycryptodome and python{,3}-pycryptodomex.

This is what I did in openarena, if it helps:
https://salsa.debian.org/games-team/openarena/commit/deaa9fc3db68733bfcb6b5edd00c97a896c3aeac

If the shared libraries that are duplicated in openarena and
openarena-server were large, I would have added an openarena-common
package instead, but they're so small when compared with an entire game
that it didn't seem worth going through NEW for that.

    smcv