Matthias Klose wrote:
> At any given time, the package `python-base' should represent the
> current stable upstream version of Python. XXX: Should we have an
> exception for the case, when a new upstream version is released during
> a Debian freeze?
It should probably be reworded so that it means the latest version we
are able to get into the release.
> Only one package may contain the `/usr/bin/python' binary and that
> package must either be `python' or a dependency of that package.
If you call the main package "python-base" then there is no "python"
package.
> There can be any number of legacy Python packages available. These
> must be named `python-<X>.<Y>' and include the file
> `/usr/bin/python<X>.<Y>'.
Here you have "python-<X>.<Y>" and elsewhere you have "python<X>.<Y>".
> 1.2. Base Package
> -----------------
>
> In order to provide a minimal installation of Python for use by
> applications without requiring the whole of Perl to be installed, the
> `python-base' package contains the binary and a basic set of modules.
Perl? Why the -base? There is not a stripped down version of Python
and a full version. Calling the package "python" is clearer, IMHO.
> Python searches three different locations for modules. The module
> search path for Debian has been ordered to include these locations at
> the beginning of the path in the following order:
>
> /usr/local/lib/site-python
> /usr/local/lib/python<X>.<Y>/site-packages
> /usr/lib/python<X>.<Y>/site-packages
That should be:
/usr/local/lib/python<X>.<Y>/site-packages
/usr/local/lib/site-python
/usr/lib/python<X>.<Y>/site-packages
> 3. Support all/most versions of python, including the default.
> Works only for architecture independant python modules. NOT YET
> SUPPORTED!!!
I assume you are refering to scheme where modules would get installed
into the search path of multiple Python interpreters. I'm not sure
that's a good idea.
> 2. You have version independant Python scripts/programs. Create a
> single package that depends on `python-base'. Any name can be
> used, but `python-<module>' is recommended for a library. It
> should install modules somewhere inside `/usr/lib/python/' and
> use `#!/usr/bin/python' for programs. The `postinst' script
> should create symlinks in all `/usr/lib/pythonX.Y/' directories
> that point to its `/usr/lib/python/' files and compile them.
If we going to do this, it's stupid for each package's pre/post scripts
to do the work. I had implemented scripts so that packages could do:
#!/bin/sh
# postinst script
PACKAGE=`basename $0 .postinst`
/usr/lib/python/install-package $PACKAGE
#!/bin/sh
# prerm script
PACKAGE=`basename $0 .prerm`
/usr/lib/python/remove-package $PACKAGE
Much cleaner and harder to screw up, IMO.
> 4.1. Building Embedded Programs
> -------------------------------
>
> Programs which embed a Python interpreter must declare a
> `Build-Depends' on `python<X>.<Y>-dev'.
Extension modules should do this as well.
> A. Upgrade Procedure
> --------------------
>
> This section describe the procedure for the upgrade from the current
> `python-<XXX> (1.5)' packages to the `python1.5-<XXX>' packages, the
> removal of the `python2-<XXX>' packages and the upgrade to the recent
> `python2.1-<XXX>' upstream packages:
>
> 1. File bugs against any packages that do not meet the above
> alternatives for packages.
I have almost all the packages fixed already (for my proposed policy,
but it would be easy to change for your proposed policy). I was going
to email the maintainers diffs.
I'm about ready to give up trying to improve the Debian/Python
situation. I assumed the Python maintainers were busy and that's why
they didn't respond to any of my posts. Now, new packages have been
installed into woody. Hmm.
Neil
