[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
signature.asc
Description: Digital signature
