Hi, On 15/08/2018 16:29, Simon McVittie wrote: > 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. > Thanks for your input. Binary .so libraries represent around 1MB out of 19MB. I will try to either change the build id with a salt or make only one dbgsym package, whichever is the easier (given a single dbgsym package would also need a test to ensure there is no missing files). -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
Attachment:
signature.asc
Description: OpenPGP digital signature