[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Python policy update



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 <abo@minkirri.apana.org.au>



Reply to: