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

[Alexis Murzeau]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/python-modules-team/attachments/20180817/b9496b55/attachment.sig>