On Sat, 2003-04-19 at 08:09, Matthias Klose wrote: > Bastian Kleineidam writes: > > On Fri, Apr 18, 2003 at 12:25:08PM +0200, Tim Dijkstra wrote: > > > On Fri, 18 Apr 2003 11:22:11 +0200 > > > Luca - De Whiskey's - De Vitis <[EMAIL PROTECTED]> wrote: > > > > file:///usr/share/doc/python/python-policy.txt.gz (that is shipped > > > > with the "python" package). > > > > > > Maybe it's a good idea to put this up the 'developers conner' > > > website along with all the other policy documents? At the moment it is > > > hard to find it if you don't know where to look. > > > > Yup, I think its time for python-policy to move > > a) on the Debian website > > b) into debian-policy (along with the Perl policy) > > I just wanted to wait for the "extended" python-central, which handles > "program packages" like mailman as well. Not sure who began to write > this ... ;-)
I've had my finger in this pie for a while, but haven't done anything for a while. There are a few things that need to be resolved in the Python policy, but I don't think this should prevent it from moving into the "official locations"... call it rev1, and when we resolve the issues, it can become rev2. 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. 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). 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. 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). 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... 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. Random thoughts: 'dpkg-reconfigure python-foo' should re-symlink and recompile python-foo for every supported version of python. Should this also remove symlinks/*.pyc's for pythonX.Y packages that have been removed? 'dpkg-reconfigure pythonX.Y' should re-symlink and re-compile every *.py that needs to be compiled by pythonX.Y. This could be done by calling dpkg-reconfigure on every package that depends on pythonX.Y (or python if python depends on this pythonX.Y?), but this would also re-compile these packages for other supported pythonX.Z's. 'dpkg-reconfigure python' should re-symlink and re-compile every *.py that depends on the default python. Should this just be call dpkg-reconfigure for the corresponding pythonX.Y? 'dpkg --remove pythonX.Y' should un-symlink and remove *.py's for all packages that supported this version of python. Perhaps do this by calling dpkg-reconfigure for those packages in the postrm script? This will trigger re-compilation for remaining supported pythonX.Y packages. 'dpkg --remove python' shouldn't need to do anything special, as any packages that depended on it should have been cleaned up by the removal of the corresponding pythonX.Y and packages that depend on only python. 'dpkg --install pythonX.Y' needs to symlink and compile every package that supports pythonX.Y. dpkg-reconfigure them? The beauty of dpkg-reconfigure is it doesn't rely on internal knowledge of dpkg or the individual packages. It allows each package to do whatever it wants in its postinst/prerm scripts and have them called whenever the "python status" of the system changes. 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. -- ---------------------------------------------------------------- Donovan Baarda http://minkirri.apana.org.au/~abo/ ----------------------------------------------------------------
