Re: Debhelper 7, Python package, multiple binary packages
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
Re: Debhelper 7, Python package, multiple binary packages
Ben Finney ben+deb...@benfinney.id.au writes: Ben Finney ben+deb...@benfinney.id.au writes: Once I learn how to make a ‘foo-dbg’ package, I can do that in the next release […] I've learned some about creating a ‘foo-dbg’ package [0]. However, I'm ending up with a source package that installs none of the Python files into any of the binary packages. Going further today, I now have a ‘python-coverage’ package that: * uses Debhelper 7.x (as before) * uses python-support (as before) * is Debian source package format “3.0 (quilt)” * has multiple binary packages and it successfully builds the original (“normal”) binary package, ‘python-coverage’. However, in doing so, 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. Also, 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’? I would appreciate some feedback again at this point, I'm going cross-eyed trying to find what is wrong and someone else can probably see it much easier. I'm not uploading it to mentors because it's not in a fit state for release. The Debian packaging is in a Bazaar repository: $ bzr branch http://bzr.debian.org/bzr/collab-maint/python-coverage/python-coverage.debian/ You can use ‘uscan’ to get the upstream source (currently version 3.2). Thanks in advance to mentors spending time to help me. -- \ “An idea isn't responsible for the people who believe in it.” | `\ —Donald Robert Perry Marquis | _o__) | Ben Finney pgp1N8WeDkyCK.pgp Description: PGP signature
Re: Debhelper 7, Python package, multiple binary packages
Le dimanche 18 octobre 2009 à 10:31 +1100, Ben Finney a écrit : = override_dh_pysupport: dh_pysupport /usr/share/backintime/ = Is this necessary? Why can't ‘dh_pysupport’ do this without being overridden here? Yes, dh_pysupport only looks at /usr/share/$package and /usr/lib/$package. Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: Debhelper 7, Python package, multiple binary packages
Ben Finney ben+deb...@benfinney.id.au writes: Ben Finney ben+deb...@benfinney.id.au writes: Once I learn how to make a ‘foo-dbg’ package, I can do that in the next release […] I've learned some about creating a ‘foo-dbg’ package [0]. However, I'm ending up with a source package that installs none of the Python files into any of the binary packages. Going further today, I now have a ‘python-coverage’ package that: * uses Debhelper 7.x (as before) * uses python-support (as before) * has multiple binary packages and it successfully builds the original (“normal”) binary package, ‘python-coverage’. However, in doing so, 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. Also, 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’? I would appreciate some feedback again at this point, I'm going cross-eyed trying to find what is wrong and someone else can probably see it much easier. I'm not uploading it to mentors because it's not in a fit state for release. The Debian packaging is in a Bazaar repository: $ bzr branch http://bzr.debian.org/bzr/collab-maint/python-coverage/python-coverage.debian/ The original source archive is the same as the previous release, URL:http://mentors.debian.net/debian/pool/main/p/python-coverage/python-coverage_3.0.1.orig.tar.gz. Thanks in advance to mentors spending time to help me. -- \ “Smoking cures weight problems. Eventually.” —Steven Wright | `\ | _o__) | Ben Finney pgpmtuTS9Rt8M.pgp Description: PGP signature
Re: Debhelper 7, Python package, multiple binary packages
On Sun, Oct 18, 2009 at 10:31:02AM +1100, Ben Finney wrote: Thanks, ‘backintime’ does indeed meet these criteria. The ‘debian/rules’ file is doing some things that I'm confused about: = override_dh_auto_clean: rm -rf locale common/po/*.mo find $(CURDIR) -name *\.py[co] -delete rm -f common/Makefile gnome/Makefile kde4/Makefile = Is it necessary to remove ‘*.py[co]’ files? Wouldn't it be better to call ‘dh_auto_clean’ to do this? They must be removed to keep the .diff.gz clean, but upstream doesn't ship makefiles with clean targets, so dh_auto_clean can't handle it. dh_clean doesn't know about pre-compiled python files. = override_dh_pysupport: dh_pysupport /usr/share/backintime/ = Is this necessary? Why can't ‘dh_pysupport’ do this without being overridden here? dh_pysupport: If your package installs private python modules in non-standard directories, you can make dh_pysupport check those directories by passing their names on the command line. By default, it will check /usr/lib/$PACKAGE, /usr/share/$PACKAGE, /usr/lib/games/$PACKAGE and /usr/share/games/$PACKAGE In my case, the package names are backintime-* but the install directory is always /usr/share/backintime, so dh_pysupport needs a little hint here. -- Jonathan Wiltshire 1024D: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Debhelper 7, Python package, multiple binary packages (was: RFS: python-coverage 3.0.1-1)
Ben Finney ben+deb...@benfinney.id.au writes: Once I learn how to make a ‘foo-dbg’ package, I can do that in the next release […] I've learned some about creating a ‘foo-dbg’ package [0]. However, I'm ending up with a source package that installs none of the Python files into any of the binary packages. Can someone point me to an existing package that: * uses ‘debhelper’ vversion 7 or later (i.e. uses the implied-sequence ‘dh’ command instead of explicit lists of ‘dh_foo’ commands) * uses ‘python-support’ * creates multiple packages, preferably including a ‘foo-dbg’ package I can't find any package that does all of those, but can't really do better than guess and manually check source packages with trial and error. [0] URL:http://wiki.debian.org/PkgSplit is really difficult to follow, probably because it needs some love from a fluent English writer. URL:http://www.debian.org/doc/developers-reference/best-pkging-practices.html#multiple-binary ignores using Debhelper 7 to avoid explicit use of ‘setup.py’ or ‘dh_install’. -- \ “Imagine a world without hypothetical situations.” —anonymous | `\ | _o__) | Ben Finney pgp0rsc3mjm0K.pgp Description: PGP signature
Re: Debhelper 7, Python package, multiple binary packages (was: RFS: python-coverage 3.0.1-1)
On Sat, Oct 17, 2009 at 11:40:07PM +1100, Ben Finney wrote: Can someone point me to an existing package that: * uses ‘debhelper’ vversion 7 or later (i.e. uses the implied-sequence ‘dh’ command instead of explicit lists of ‘dh_foo’ commands) * uses ‘python-support’ * creates multiple packages, preferably including a ‘foo-dbg’ package IIRC, backintime does all but the -dbg of these things. -- Jonathan Wiltshire 1024D: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debhelper 7, Python package, multiple binary packages
Jonathan Wiltshire deb...@jwiltshire.org.uk writes: On Sat, Oct 17, 2009 at 11:40:07PM +1100, Ben Finney wrote: * uses ‘debhelper’ vversion 7 or later […] * uses ‘python-support’ * creates multiple packages, preferably including a ‘foo-dbg’ package IIRC, backintime does all but the -dbg of these things. Thanks, ‘backintime’ does indeed meet these criteria. The ‘debian/rules’ file is doing some things that I'm confused about: = override_dh_auto_clean: rm -rf locale common/po/*.mo find $(CURDIR) -name *\.py[co] -delete rm -f common/Makefile gnome/Makefile kde4/Makefile = Is it necessary to remove ‘*.py[co]’ files? Wouldn't it be better to call ‘dh_auto_clean’ to do this? = override_dh_pysupport: dh_pysupport /usr/share/backintime/ = Is this necessary? Why can't ‘dh_pysupport’ do this without being overridden here? -- \ “Two possibilities exist: Either we are alone in the Universe | `\ or we are not. Both are equally terrifying.” —Arthur C. Clarke, | _o__) 1999 | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
