On Wed, 2003-08-20 at 22:09, Josselin Mouette wrote: > In order to make it up to date, and to match current packaging > practices, I have prepared a draft for a python policy update. > It is available at: http://people.debian.org/~joss/python/ > > It includes clarifications, a new section on bytecompilation, treats the > case of private modules, and appendix B now describes a transition like > the current one (which is likely to happen again in the future). > > Please comment.
Nice work... have some contributions to make; --- 1.2 Main Package, last paragraph < At any time, exactly one package must contain a binary /usr/bin/python. That package must either be python or a dependency of that package. > At any time, the python (X.Y) package must contain a symlink /usr/bin/python to the the appropriate binary /usr/bin/pythonX.Y. The python package must also depend on the appropriate pythonX.Y to ensure this binary is installed. --- 1.2.3 Interpreter location, last paragraph < The preferred specification for the Python interpreter is /usr/bin/python or /usr/bin/pythonX.Y. < < If a maintainer would like to provide the user with the possibility to override the Debian Python interpreter, he may want to use /usr/bin/env python or /usr/bin/env pythonX.Y. > The preferred specification for the Python interpreter is /usr/bin/python or /usr/bin/pythonX.Y. This ensures that a Debian installation of python is used and all dependencies are met. > > If a maintainer would like to provide the user with the possibility to override the Debian Python interpreter, he may want to use /usr/bin/env python or /usr/bin/env pythonX.Y. However this is not advisable as it bypasses Debian's dependency checking and makes the package vulnerable to broken local installations of python. --- 1.4 Module Path, a question; Do we really want /usr/local/ on the python path before /usr/lib/? This makes us vulnerable to busted local installs of python modules, in the same way that "#!/usr/bin/env python" makes us vulnerable to busted local installs of python. --- 2.2.1 Support Only The Default Version, questions and typo on last paragraph We should mention programs should use #!/usr/bin/python. I think "Build-Depends: python-dev (>= X.Y)" should be Build-Depends: python-dev (>=X.Y), python-dev (<<X.Y+1)", or doesn't Build-Depends support that. In any case, >=X.Y is not sufficient to nail it down. last TODO should have pythonX.Y-foo, not python-fooX.Y --- 2.2.3 Support All/Most Versions (Including Default), regarding 2. Part 2. still includes the unsupported stuff about using /usr/lib/python/site-packages. There was some discussion about using /usr/lib/site-python for this instead... should this be updated? --- 3.1 Version Independent Programs, comments This strikes me as a mix of a few different alternatives. perhaps these should be separated out and explained a bit better. Anything that puts stuff in /usr/lib/pythonX.Y or depends on "python (>=X.Y), python (<<X.Y+1)" is not really version independent. Perhaps this should be re-titled "Programs using the default python", and the following section should be called "Programs using a particular version of python" The last para about "private modules" should also apply against anything that goes in /usr/lib/site-python and is only true because currently there is no mechanism to re-compile version independent packages when python (X.Y) upgrades. The moment python (X.Y) (and perhaps pythonX.Y) is capable of identifying dependent packages and re-compiling them, then there is nothing stopping dependencies like "python (>=2.0), python (<<2.4)". -- Donovan Baarda <[EMAIL PROTECTED]>