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

[Piotr Ozarowski]

[Jonas Smedegaard, 2010-12-30]
> On Fri, Dec 10, 2010 at 12:07:36AM +0100, Matthias Klose wrote:
> >A package which build-depends on python-dev and not python-all-dev
> >should only be built with the default python version.
> 
> Is that a fact, or do you propose this behaviour?

that's a common practice, yes. Debian Python Policy describes
python{,-dev,-all,-all-dev} packages here¹.

[¹] http://www.debian.org/doc/packaging-manuals/python-policy/ap-build_dependencies.html

> Seems wrong to me to mandate such behaviour based on direct build
> dependencies.

some packages use standard CDBS/dh build system (i.e. without overrides
to build using one Python version only) and later move Python
modules from public place ({site,dist}-packages/) to a private
directory. ">= 2.4" in XS-Python-Version is still valid as the (private)
module works fine with all Python versions (binNMU will be needed if it
contains private extension, otherwise helper tools will just regenerate
.pyc files when new default Python version will be installed).

I think Build-Depends is the best place to mark such cases (where only
one Python version is needed at build time).

The other way to fix this bug is to adjust pyversions tool to parse
build dependencies and return one Python version only, I'm not sure if
it's a good idea, though (but since dh_py* helper tools will ignore² it,
and bytecompile/create symlinks for all requested Python versions, maybe
it's something we can do (and avoid "current" problems at the same time)
Matthias and Scott: if you think it's a good idea, I will implement it.

[²] note the difference between this behaviour and the one with
    "current" keyword

PS Note that even if you will build for one Python version only, Python
helpers will try to deal with that - dh_pycentral and dh_pysupport will
generate symlinks at install time anyway; if package is using
XB-Python-Version, we'll detect missing extensions (for arch:any
packages) during the transition. dh_python2 will create missing symlinks
at build time and FTBFS if it will detect a missing extension

> >Both debhelper and cdbs now try to build for the intersection of
> >the installed and requested python versions (which only depends on
> >the installed pythonX.Y packages, but not the pythonX.Y-dev
> >packages), and then fail to build not finding e.g. headers in the
> >non-default pythonX.Y-dev package.
> 
> 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

[...]
> >In the past we had the XS-Python-Version: current attribute for
> >this scenario, but that was ditched for reasons not entirely
> >understood by me.

"current" does more than that (building for one Python version) - it
uses one Python version even at runtime. Public Python modules should be
available for as many installed Python interpreters as possible (limited
only by upstream author, not by us) and "current" keyword provides more
harm than good by limiting public module's list of supported Python
versions, IMHO. It was deprecated because you can get exactly the same
effect by installing your module as private one (and not messing with
public ones).

> 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)

> 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)

[/me subscribed bug#606530]

PPS a lot of things will (hopefully) be simplified in Wheezy (due to the
fact that we will most probably support one Python 2.X version only -
the last one³, and due to upstream changes in Python 3.X interpreters)

[³] upstream will never release Python 2.8
-- 
Piotr Ożarowski                         Debian GNU/Linux Developer
www.ozarowski.pl          www.griffith.cc           www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/build-common-hackers/attachments/20101230/cade35b2/attachment.pgp>