My attempt to merge python-central and python-support failed few months ago, so
here's another proposal to improve the Python situation in Debian. It's nothing
new
actually, just a compilation of previous Matthias' and Joss' ideas and few of my
own.
The main idea is to ship symlinks (not .pyc files!) in binary packages as
Matthias proposed back in February and thus get rid of both helper tools (most
problems with current tools occur at install / upgrade time). I want to keep it
as simple as possible and let maintainers customize it in maintainer or
rtinstall/rtupdate/rtremove scripts (if really needed).
Advantages:
* a lot less opportunities to break a system while installing / upgrading
Python packages,
* no more problems with packages that provide the same namespace and use
different helper tool,
* Python modules available out of the box (think about daemons),
* no more "which tool should I use?" or "how do they differ?" questions ;-)
The main disadvantage of this approach is that architecture independent packages
will have to be rebuilt once new Python version will be added to the supported
ones
(I think we can avoid a rebuild if a version is removed from the supported
ones).
Luk (our release manager) told me that binNMUs for arch:all packages will be
possible in Debian at some point, but it's a matter or months or even years, so
for now - manual NMUs will be needed. I think it will be easy to detect which
packages need one basing on Contents file and Depends field.
Another disadvantage is the fact that pysupport's namespace feature will not be
supported. If we want to keep it simple and let dpkg know about all the files -
new *-common package with all common __init__.py (and other if needed) files
will have to be provided, just like we did before pysupport 0.7. Otherwise
removing .pyc files will not be a trivial thing to do. Note that there are lots
of problems with this feature anyway (upstreams tend to use site-packages for
things that don't belong there), so removing it will improve the situation at
the end, IMHO.
I'll try to make dh_python a drop in replacement for dh_pycentral and
dh_pysupport (i.e. tools used at build time) for most packages, but I don't
consider it to be a main goal. Some packages will have to be manually updated
(f.e. the ones that use pysupport's namespace feature).
I want the tool to be team maintained, I didn't decide yet if new Alioth
project should be created or if we should use DPMT or PAPT repo for this,
though.
Short overview of how things will work with new dh_python:
==
build time:
^^^
* files installed into the standard location[1] or into private directory
* dh_python will:
- move .py files from SL[1] into /usr/share/py{,3}shared,
- move .so files to /usr/lib/pythonX.Y/*-packages if /usr/local was used,
- create symlinks for all py{,3}shared content in
/usr/lib/pythonX.Y/*-packages
*if* files are the same for all Python versions in SL[1] (if not, leave
original files) where X.Y are requested Python versions,
- create simple maintainer scripts with pycompile and pyclean commands
and (if needed) rtupdate script (for private directories that use default
Python version). Private modules that cannot be used with default Python
version will get additional pycompile command with all needed arguments,
like
minimum required Python version or hardcoded one in both, maintainer script
and rtupdate one
[1] SL = standard distutils/setuptools location:
/usr/{,local}/lib/pythonX.Y/{site,dist}-packages/
installation time:
^^
* maintainer script should bytecompile pyc files for all provided
symlinks / private directories if given Python version is installed
* user installs new pythonX.Y package:
- bytecompile related symlinks (pycompile -V X.Y)
* user removes pythonX.Y package:
- remove all pythonX.Y's .pyc files (pyclean -V X.Y)
- all packages with private directories that use this Python version will be
removed
by dpkg (Depends field will do its job)
* default Python version changes:
- rtupdate scripts for packages with private modules that support it (i.e.
the ones without hardcoded Python version and without private extensions)
invoked
examples:
=
example 1 - public modules/extensions only
^^
$ python2.4 ./setup.py install --root=debian/python-foo/
debian/python-foo/usr/lib/python2.4/site-packages/foo/__init__.py
debian/python-foo/usr/lib/python2.4/site-packages/foo/_foo.so
debian/python-foo/usr/lib/python2.4/site-packages/foo/bar.py
debian/python-foo/usr/lib/python2.4/site-packages/spam.py
$ python2.5 ./setup.py install --root=debian/python-foo/
debian/python-foo/usr/lib/python2.5/site-packages/foo/__init__.py
debian/python-foo/usr/lib/python2.5/site-packages/foo/_foo.so
debian/python-foo/usr/lib/python2.5/site-packages/foo/bar.py
debian/python-foo/usr/lib/pyt
