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
