On Fri 2020-01-10 18:16:37 -0500, Daniel Kahn Gillmor wrote:
> I took one more step at debugging the newly-built modules to try to
> understand why the non-stripped versions might differ, and noticed that
> the debugging info in each module itself is different. in particular,
> in the 3.7 module, the debugging info contains different paths:
>
> -./bindings/python-cffi/build/temp.linux-amd64-3.7/notmuch2._capi.c:1272
> +./bindings/python-cffi/build/temp.linux-amd64-3.8/notmuch2._capi.c:1272
>
> (notmuch2._capi.c is a generated C file here, iiuc)
>
> so maybe the build-id is being generated based on the contents of the
> debug info, in addition to the contents of the stripped-down data?
FWIW, I think the above is indeed what is happening -- we're getting
different build-ids because the paths to the source files (to be stored
in the debug info) are different.
I talked with folks on #debian-python, and they said, basically
(paraphrasing):
Don't worry about the fact that we're shipping two distinct .so's,
because debian will only release with one version of python anyway.
It's an artifact that is only relevant for testing, during the
transition.
So i hope my public diagnosis of this concern didn't scare people off of
this patch. We should apply it and ship it in debian.
--dkg