[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Making multiple-version Python packages with debhelper?

On Tue, Mar 07, 2006 at 14:50:12PM +0100 Florian Ragwitz wrote:
> On Tue, Mar 07, 2006 at 11:23:41AM +0200, Panu Kalliokoski wrote:
> > Hello, I was asked to make my python-selecting package support
> > multiple
> > Python versions.  Does somebody know the proper way to achieve that
> > with
> > debhelper (using dh_python in some way perhaps?), or a pointer to
> > such
> > information?
> Take a look at the [1]rules file for python-bluetooth, prepared by
> michal@cihar.com.
> [1] http://files.perldition.org/python-bluetooth.rules
Some comments on this package, just for fun:

I don't see any reason why errors here should be ignored:
-rm -rf build
python$$v setup.py clean || true; \

Also, it would be good to prefix both of the loops with "set -e;"; in
the case that the loop has only one command, this probably doesn't do
anything, except error if the loop syntax itself is bad; in the case
of multiple commands, it does the right thing, though.

install: build
binary-indep: build install
binary-arch: build install

binary-* shouldn't need to depend on build, since they do so directly
through install anyway.

The duplicated debhelper foo could be replaced with logic similar to
that found in /usr/share/debhelper/dh_make/debianm/rules, which
exports DH_OPTIONS, and calls a "binary-common" rule with it set to
either "-i" or "-a".

.PHONY references the nonextant target 'configure'.

I also note that the package does a really good thing:
	rm -f build-stamp
It does this as the first action (besides dh_test{dir,root} of
"clean", so a user interrupt or clean error won't leave the "stamp"
file around when in fact the build has been partially undone.  This is
suggested in policy 4.8, and I have #348620 against lintian requesting
to check for this best-practice.



Reply to: