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
