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]
