Ben Finney 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
