On Thu, 06 Apr 2017 at 17:49:15 +0200, Thomas Goirand wrote: > Attached is the debdiff. As you can see, I'm attempting to use the new > system that creates -dbgsym, and transitioning to it.
Sorry, I don't think this is a correct solution. For non-Python packages, foo-dbg traditionally contained detached debug symbols for the "production" version of foo (for example libglib2.0-0-dbg contained debug symbols that were stripped from the libraries and binaries in libglib2.0-0 and libglib2.0-bin). This can easily be superseded by -dbgsym packages. However, for Python packages, python[3]-foo-dbg has traditionally contained two distinct types of content: * Detached debug symbols as above * A version of the same Python libraries as python[3]-foo, but recompiled with different options such that they can be imported into the debug interpreter python[3]-dbg (whose ABI is not the same as python[3]) You're keeping the first but losing the second. Is this intentional? Is this correct? It is certainly not correct to keep the -dbg packages and make them transitional. I'm not sure whether this is considered to be a Policy violation (-dbgsym packages are not in the main archive), but it's certainly unconventional; and in this case, the -dbgsym package does not correctly provide (all the functionality of) the -dbg package, because the -dbg package contained libraries for the debug interpreter and the -dbgsym package does not. With hindsight, Python packages should probably not have ended with -dbg, because that misleads developers like you into thinking they are basically the same thing as libglib2.0-0-dbg - they aren't. Perhaps they should have been like python[3]-dbg-cassandra instead, which would make it a little clearer that they are a plugin for python[3]-dbg. Normally, dropping -dbg packages looks like this: https://anonscm.debian.org/cgit/pkg-games/ioquake3.git/commit/?id=87594a58b03b850569357543b3823954b4fb0e73 > Also, does #857298 really deserves severity "grave"? Are others sharing > the view that it could be downgraded to "important"? It is grave for the binary package, because on the affected architectures, python-cassandra-dbg is useless: it fails to meet its intended purpose (letting users of python-dbg "import cassandra"). Unfortunately, autoremovals act on source packages, not binary packages, because we don't want to remove individual binary packages from testing. Perhaps removing the binary package is the best resolution - I don't know. It's certainly the easiest. However, you need to be aware that this is what you're doing: deliberately removing functionality. S