Bug#606530: [Build-common-hackers] Bug#606530: Bug#606530: packages build-depending on python-dev should not be built for non-default python version

2018-06-10 Thread Niels Thykier
reassign 606530 cdbs
thanks

On Thu, 30 Dec 2010 12:53:28 +0100 Jonas Smedegaard  wrote:
>[...]
> >
> >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
> 
> [..]

Reassign this to cdbs.  As of debhelper/11.3, debhelper has deprecated
its python build system and is now recommending the pybuild build system
instead.

Thanks,
~Niels



Bug#606530: [Build-common-hackers] Bug#606530: Bug#606530: packages build-depending on python-dev should not be built for non-default python version

2010-12-30 Thread Jonas Smedegaard

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 package


even 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