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 writes: > Ben Finney 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, 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
Re: License entry in egg info files
Ben Finney wrote: > Paul Wise writes: > >> Do you object to spelling-error-in-binary, >> duplicated-key-in-desktop-entry, embedded-zlib, duplicate-font-file or >> the other lintian tests that check upstream stuff? > > I think they lead to widely-used, persistent overrides, and I think such > overrides are an indicator that the specific check is inappropriate. Usually an override is a fail in the maintainer's brain or a bug in lintian. Only in rare cases overrides are the right way to go. -- 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: License entry in egg info files
Bernd Zeimetz writes: > Usually an override is a fail in the maintainer's brain or a bug in > lintian. Only in rare cases overrides are the right way to go. Yes, that's pretty much my point: that *if* a Lintian check leads to many maintainers adding an override for that tag that persist over time, then probably the check was badly implemented or a bad idea in the first place. -- \ “I thought I'd begin by reading a poem by Shakespeare, but then | `\ I thought ‘Why should I? He never reads any of mine.’” —Spike | _o__) Milligan | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
