Ben Finney <ben+deb...@benfinney.id.au> writes: > […] while the ‘python-coverage’ binary package is now building > correctly, the ‘python-coverage-dbg’ binary package contains nothing > useful; it's as though there is no content for that package detected > by the tools. Isn't that exactly why I'm using Debhelper >= 7.3.5 in > the first place: to automatically handle the debug package based on > ‘Build-Depends: python-all-dbg’?
It turns out that ‘dh_strip’ can't tell what debug package name it should use, and needs to be told explicitly. With an explicit override to run ‘dh_strip --debug-pkg=python-coverage-dbg’, the debug package is now correctly generated. Would it be reasonable to change the default behaviour of ‘dh_strip’ to guess the package name in the common case where there are declared packages ‘foo’ and ‘foo-dbg’ (where the latter is ‘Section: debug’)? Are there any nasty ramifications to such default behaviour? > [in order to generate a ‘foo-dbg’ package] I've had to fall back on > explicitly iterating Python versions and explicitly calling ‘setup.py > install’, which partly defeats the purpose of using Debhelper 7 and > python-support. This is frustrating, and I wonder if I'm missing some > simpler way to do multiple binary Python packages with these tools. I would still love to know whether Debhelper can be of more assistance with this. -- \ “Every man would like to be God, if it were possible; some few | `\ find it difficult to admit the impossibility.” —Bertrand | _o__) Russell, _Power: A New Social Analysis_, 1938 | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org