Manuel Prinz <[EMAIL PROTECTED]> writes: > I have a Python application with private extension modules, so the package is > Arch: any. Because there is no way (at least I'm not aware of that) to split > the package because the modules are private, I can't seperate the large part > of the app out to /usr/share/package/ because the extension module parts > under /usr/lib/package/ can't be loaded. Is there a way to do that or is the > recommended way to put everything to /usr/lib/package/ even thought large > parts are arch-indep?
You're welcome to copy the approach I take with BitPim, which is in the same boat: the main package (bitpim) is architecture-independent and installs its Python modules under /usr/share (specifically, in /usr/share/bitpim/code). However, because a couple of modules are architecture-dependent, they go into a separate bitpim-lib package on which bitpim depends, with a carefully crafted __init__.py that lets Python find them: $ cat /usr/share/bitpim/code/native/__init__.py # Handle Debian's split-up layout __path__.insert(0, '/usr/lib/bitpim/native') I suspect one could do the same with a .pth file. > Also, is it OK to build just against the default Python version in Debian or > should all versions be supported? Upstream's build system does not enable to > build against a specific version of Python. You shouldn't need to build against multiple Python versions as long as you arrange for inter-package dependencies to be bin-NMU safe (no strict all -> any dependencies). > P.S.: Please CC me in replies, I'm not subscribed. Done; thanks for warning us. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
