Re: What to do when a source package has Python components in a subdir?

[Matthias Klose <doko@cs.tu-berlin.de>]

Zack Weinberg writes:
> Since Python policy is being revamped just now I thought I'd bring up
> a complicated situation that I ran across recently (in packages that
> are currently just for private use, but I might try to get them into
> Debian eventually).
> 
> Consider a source package that builds a shared library, Python
> bindings for that library (consisting of both "extensions" and
> "modules"), and programs for /usr/bin that are written in Python and
> use the library bindings.  Upstream distributes this as one big
> tarball with a top-level autoconf-based configure script and Makefile.

I assume these bindings are for public usage.

>  The Python bindings are in a subdirectory; Make recurses into that
> directory and invokes setup.py there.  Upstream makes no provision for
> building the bindings against multiple versions of Python; however,
> they work fine with all versions I've tried (2.3 and 2.4).
> 
> Policy questions:
> 
> * What is the appropriate set of binary packages for this scenario,
> and what goes in each?

- the minimum would be one binary package

- a python-foo package can be split out (if there is a large chunk of
  modules, it could further be split out into a python-foo and
  python-foo-bin package.

> * What should the /usr/bin programs have on their #! line?  (I assume
> /usr/bin/python, i.e. the default version, but explicitness would be
> good.)

yes, we should mention that. I'm not sure, how /usr/bin programs
should be handled which are installed versioned (foo-py23-bin,
foo-py24-bin) and use the versioned interpreter explicitely.  Just
remove them, and keep foo-bin, or keep them all, but do not
explicitely depend on the versioned python packages.

> Packaging practices question:
> 
> * What is the best way to code debian/rules for this scenario?  Hack
> up the upstream Makefiles to run setup.py repeatedly, or have
> debian/rules reach in there and invoke it itself, or what?

depends on the packaging system, but that decision is up to the
package maintainer. I looked once at subversion and just
did build the whole stuff twice. If you have the possibility to just
build the python stuff, then maybe build the package for the default
version completley, and then for the other versions

EXTRAVERS := $(filter-out $(shell pyversions -d), $(shell pyversions -r))

build: $(EXTRAVERS:%=build-python%)
build-python%:
	python$* setup.py build
install: build $(EXTRAVERS:%=install-python%)
install-python%:
	python$* setup.py install --no-compile \
	    --root $(CURDIR)/debian/python-foo

Hacking the upstream Makefiles should be done independently from the
currently supported python versions.

  Matthias