Re: Packaging question on private extension modules
Manuel Prinz <debian@pinguinkiste.de> 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/?amu@monk.mit.edu
Reply to: