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