On Thu, Dec 30, 2010 at 11:38:47AM +0100, Piotr Ozarowski wrote:
CDBS currently by default build for all variants of Python available at build time. It is then the responsibility of the packageeven if we will change pyversions to parse Build-Depends, please try to build for all interpreters returned by `pyversions -r`, do not limit it to the ones installed, it's much better to FTBFS if given interpreter is missing than to build with missing extensions
Please document *independently* of high-level helper tools the best practice of Python packaging. Then point us developers of high-level packaging helper tools to that documentation, and let's work from there.
CDBS provides helper tools for packaging, not (if we can avoid it) band-aid for lack of sensible logic in underlying build infrastructures.but there's *is* a logic: build depend on python or python-dev or pythonX.Y-dev if you want to build for one Python version only and build depend on python-all/python-all-dev if you want to support more than one Python version (i.e. your package provides public module)
Where is that logic documented?If you mean that CDBS python snippets has a logic, then *no* - don't lean on that: The hacks applied to the CDBS puthon*.mk snippets back in 2006 as part of the transition to Python policy 2 was a disaster that I am still trying to both understand and to adjust for.
I sugest you resolve Python build systems issues internally among the build infrastructures python-central python-support and python-default, and then tell us package helper folks what you came up with which we can then support from a higher altitude.as noted before, dh_py* helper tools know how to deal with this situation, the only problem is with cdbs/dh → pyversions. We can either fix it in CDBS/dh or in pyversions (if both CDBS and dh will try to build for all `pyversions -rv` versions and not only for `pyversions -riv` or `pyversions -iv` ones)
Great that dh_py* tools are good. Now please document independently of high-level packaging tools (like CDBS and short-form dh) how this goodness is intended to be used, and point us to that documentation.
- Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: Digital signature