Donovan Baarda writes: > The things that need resolving, in no particular order; > > 1) moving /usr/lib/python* into /usr/share/python*. I consider this low > priority, but something that should be done one day. There are possibly > some issues with separating binary extension modules from .py python > modules that would to be resolved.
-1 As we change the search order, I will wait until upstream applies this (or at least discussed it). The right way here seems to write a PEP. > 2) python-central style support for pure-python modules that support > more than one version of the default python package. The current version > of python-central can already do this, but it is not in the standard > yet. I'm not sure if it should be standard untill it suppprts 3). +1 > 3) python-central style support for python programs that support more > than one version of the default python package. In particular, this is > for packages that have "non-public" python modules that are not > installed in /usr/lib/python/. Currently python-central does not do > this. +1 > After having contributed to python-central, I'm still not sure it's the > best way to do things. It would be nice to avoid having a separate > package just for python installation scripts. However, it is the only > way I can think of to have common installation scripts available to all > python packages without requiring the installation of "python" (ie, > python1.5-foo only requires python1.5, why should it require python > (2.1), and hence python2.1, be installed). what is wrong to have a default python version installed? Many packages already use python, so it's likely to be installed on a machine. > The only alternatives are to have something like dh_python replicate the > required functionality in every package's postinst/postrm scripts. > Perhaps a variant of this would be to provide the supporting scripts in > every pythonX.Y package. Hmmm... -1. > If every python package ensured that it symlinked (if required) and > compiled it's .py's for every installed and supported version of python > in it's postinst, then doing a 'dpkg-reconfigure -p critical <package>' > should re-compile the package. There must be ways to use this in scripts > to ensure correct installation-removal of packages. [...] hmm, how does this work for packages like mailman and zope, where more than recompilation is done in the scripts (debconf configs ...)? I don't want be asked these questions when I upgrade python. > The problem of dpkg-reconfigure is it brute-forces everything without > taking into account the specifics of what the "python status" change is. > Perhaps a better way to do this is to instead just call the package > .postinst scripts, adding a few extra "context cue" parameters to tell > the package what has happened. For example call > "/var/lib/dpkg/info/python-foo.postinst configure pythonX.Y" when > pythonX.Y is installed and "/var/lib/dpkg/info/python-foo.prerm > pythonX.Y" when pythonX.Y is removed. Then we are at a point, where we need a <package>.python file (maybe in dpkg format), which contains the python specific meta information. Matthias