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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]