Re: Fw: RFS: python-coverage 3.0.1-1
Ben Finney wrote: The changelog entry for ‘debhelper’ 7.3.5 says: * python_distutils buildsystem: Build for all supported Python versions that are installed. Ensure that correct shebangs are created by using `python' first during build and install. Closes: #520834 Also build with python*-dbg if the package build-depends on them. What does it mean “if the package build-depends on them”? If “them” means “debug packages”, why would any non-debug package depend on a debug package? Checking if -dbg interpreters are installed is not enough to decide if you want to buiid with them as you don't necessarily have a clean chroot. So dh needs to look into the build-deps. debian/python-coverage.dirs: * Useless. I can't find where ‘/usr/bin/’ is excluded from requirement to be created; is it in a part of Policy that I've overlooked? There is no need to use a .dirs file if setup.py creates the directory for you. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Fw: RFS: python-coverage 3.0.1-1
Bernd Zeimetz be...@bzed.de writes: Ben Finney wrote: I can't find where ‘/usr/bin/’ is excluded from requirement to be created; is it in a part of Policy that I've overlooked? There is no need to use a .dirs file if setup.py creates the directory for you. Gotcha. Okay, removed. The changelog entry for ‘debhelper’ 7.3.5 says: * python_distutils buildsystem: […] Also build with python*-dbg if the package build-depends on them. What does it mean “if the package build-depends on them”? […] Checking if -dbg interpreters are installed is not enough to decide if you want to buiid with them as you don't necessarily have a clean chroot. So dh needs to look into the build-deps. Ah, I see. So this means it will check the ‘Build-Depends’ field for the packages ‘python2.4-dbg’, ‘python2.5-dbg’, or ‘python-all-dbg’; nothing to do with dependencies on ‘foo-dbg’. Right? -- \ “I call him Governor Bush because that's the only political | `\ office he's ever held legally.” —George Carlin, 2008 | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Fw: RFS: python-coverage 3.0.1-1
Luca Falavigna dktrkr...@debian.org writes: It seems my message didn't passed through, so I re-send it, I hope with a better fate. We got it this time. Thank you for inspecting this package. debian/control: * Build-Depend on debhelper (= 7.3.5). The changelog entry for ‘debhelper’ 7.3.5 says: * python_distutils buildsystem: Build for all supported Python versions that are installed. Ensure that correct shebangs are created by using `python' first during build and install. Closes: #520834 Also build with python*-dbg if the package build-depends on them. What does it mean “if the package build-depends on them”? If “them” means “debug packages”, why would any non-debug package depend on a debug package? debian/python-coverage.dirs: * Useless. I can't find where ‘/usr/bin/’ is excluded from requirement to be created; is it in a part of Policy that I've overlooked? debian/python-coverage.install: * I'd use debian/manpages to install python-coverage.1. Done. debian/rules: * Why did you rename /usr/bin/coverage to /usr/bin/python-coverage? Because ‘/usr/bin/coverage’ is far too generic a name for a tool specifically for checking Python source code. (This change was made before I started maintaining the package, but I agree with it on this rationale.) * Pass --single-version-externally-managed to setup.py install. The package doesn't directly use ‘setup.py install’ at all, leaving that to the various ‘debhelper’ programs. In what circumstances does a package need your suggested change to override what those helpers do by default? * You could eventually adopt rules.tiny to simplify reading. That template omits the ‘.PHONY’ rules (marking some targets as phony so they will be built regardless whether there is a file of the same name). I think those rules serve a good purpose, so I use a ‘debian/rules’ file that declares them. debian/watch: * Newest version on remote site is 3.1~b1, local version is 3.0.1, you could want to exclude beta releases. I prefer to make this determination for each release, rather than have them omitted by default. Is there a reason this is a bad practice? Thanks again for your feedback. -- \ “Shepherds … look after their sheep so they can, first, fleece | `\ them and second, turn them into meat. That's much more like the | _o__) priesthood as I know it.” —Christopher Hitchens, 2008-10-29 | Ben Finney pgpQxLaodJeyl.pgp Description: PGP signature