Re: Packaging question on private extension modules
Le samedi 31 mai 2008 à 22:00 +0200, Manuel Prinz a écrit : > 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? At least, current practice in this case is to put everything in /usr/lib. > 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. For private extensions, it is quite complex to support multiple python versions as you need a specific rtupdate script, so in general you should not do that. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Packaging question on private extension modules
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]
Re: Packaging question on private extension modules
Am Montag, 2. Juni 2008 14:52:05 schrieb Josselin Mouette: > At least, current practice in this case is to put everything > in /usr/lib. This is something I did and of course works. Currently I do install everything into /usr/share except the binary parts (.so files). I have those in /usr/lib and symlink to them in /usr/lib. I did so because it is trivial to split the packages into Arch: all and any but I'm still uncertain about splitting the package since it is rather small: about ~650kb total, binary parts are just a few kb. Is there a rule of thumb when it's reasonable to split? Thanks to everyone who answered so far! Best regards Manuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
