Re: python packaging infrastructure

[Matthias Klose <doko@cs.tu-berlin.de>]

Josselin Mouette writes:
> Le lundi 16 janvier 2006 à 15:24 +0100, Matthias Klose a écrit :
> > This is the right direction, and adding support for extensions makes
> > this complete. Does your proposal allow rebuilding these packages
> > without actually changing anything (except the changelog).
> 
> Being able to rebuild packages for a new python version without changing
> anything was the purpose of dh_python from the very beginning, for both
> packaging styles:
>       * for packages with a single python-foo package containing
>         extension foo, build-depending on python-dev, a rebuild will
>         generate a new package built against the new version;
>       * for packages with python2.3-foo and python2.4-foo, a rebuild
>         will make python-foo depend on the new version. The only case
>         that isn't handled is when the package isn't maintained much,
>         and lacks python2.5-foo when the python2.5 transition
>         approaches.
> This is independent of python-support.

the design decision of putting the binary-all python packages in a
separate directory into /var/lib/python2.x/site-packages has some
problems when supporting packages with extensions (a proposal beeing
made on #irc was to keep the extensions in the standard path).

suppose you have the following scenario

/usr/lib/python2.3/site-packages/foo/
	__init__.py
	fooext.so (doing a "import foomod")
	foomod.py

which is splitted into (by python-support)

/usr/lib/python2.3/site-packages/foo/
	__init__.py
	fooext.so

/var/lib/python2.3/site-packages/foo/
	__init__.py
	foomod.py

Having /var/lib/python2.3/site-packages appended to sys.path let's the
import of foomod fail (cannot be found).  Using just one package
directory inside /usr/lib/python2.3/site-packages does avoid the
problem (the way the current python-central works).

  Matthias