Package: python-coverage-dbg Severity: important Version: 3.4-3 Control: submitter -1 Barry Warsaw <ba...@debian.org>
On 02-Nov-2013, Barry Warsaw wrote: > On Nov 02, 2013, at 09:27 AM, Ben Finney wrote: > > >The debug symbols are created by stripping the debug symbols from the > >normal object files, and installing them only in the debug package > ><URL:https://wiki.debian.org/DebugPackage>, in our case by the > >‘override_dh_strip’ and ‘install’ targets of the rules file. > > Right, but for Python that's not enough. > > https://wiki.debian.org/Python/DbgBuilds > > That page is a little out of date (e.g. python-support) but the gist of > it is still relevant. When you run python-dbg or python3-dbg, you're > getting the debug build of Python. Since the debug build has a different > ABI than the non-debug build, extension modules have to be built and > provided for each. Debug build Python will refuse to import non-debug > build extensions and vice versa, because of the different ABI. This was > one of the main impetuses behind PEP 3149. > > http://www.python.org/dev/peps/pep-3149/ > > As an example, take a look at dbus-python and especially the > python{,3}-dbus-dbg binary packages. E.g. the latter contains the > debugging symbols, but it also contains a /usr/lib/python3/dist-packages/ > _dbus_glib_bindings.cpython-33dm-x86_64-linux-gnu.so file. Note the > '33dm' tag. > > As is usual, Python 2 is different in some details, but essentially the > same. In Debian, the debug build extensions have a non-standard _d.so > suffix. Again, I think dbus-python is a good example. Okay. This has been a bug for many releases of ‘python-coverage’, then. Can we deal with this as “Severity: important” for the debug packages, but wait until after uploading 3.7+dfsg.1-2 fixing bug#727711? -- \ “[W]e are still the first generation of users, and for all that | `\ we may have invented the net, we still don't really get it.” | _o__) —Douglas Adams | Ben Finney <b...@benfinney.id.au>
signature.asc
Description: Digital signature
