Neil Schemenauer writes:
> 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.
Done.
> > 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.
Corrected.
> > There can be any number of legacy Python packages available. These
> > must be named `python-.' and include the file
> > `/usr/bin/python.'.
>
> Here you have "python-." and elsewhere you have "python.".
Corrected.
> > 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.
If I remember correctly, Gregor called the package not like the source
package, because not all stuff from the source is included in this
package. What is the content of the current pythonX.Y-base? All arch
independent modules plus all arch dependent modules, which are
installed on a Debian system anyway (zlib, libdb, libbsddb, readline,
any more?)
Was the separate python-zlib package intentional?
> > 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./site-packages
> > /usr/lib/python./site-packages
>
> That should be:
>
>/usr/local/lib/python./site-packages
>/usr/local/lib/site-python
>/usr/lib/python./site-packages
Corrected.
> > 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.
No. This was Donovan's proposal from
http://lists.debian.org/debian-python/2001/debian-python-200110/msg00067.html:
The modules should be installed into /usr/lib/python/site-packages,
which is not included in sys.path. Donovan's proposal was linking each
file to all /usr/lib/pythonX.Y/site-packages:
for dir in /usr/lib/python*.*; do
version=`echo $dir | sed "s/^.*python//"`
cp -Rsu /usr/lib/python/* $dir
done
> > 2. You have version independant Python scripts/programs. Create a
> > single package that depends on `python-base'. Any name can be
> > used, but `python-' 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.
Ok. /usr/lib/python/install-package should be part of python-base,
which calls each /usr/lib/pythonX.Y/install-package from
pythonX.Y-base, which is currently installed. If a new pythonX.Y is
installed, it calls /usr/lib/pythonX.Y/install-package for all
installed packages.
Only in the last packaging case (arch independent module for more than
one version), you would call /usr/lib/python/install-package
directly. In all other cases you have to call
/usr/lib/pythonX.Y/install-package directly.
Anthony Towns had doubts, if such a schema is worth implementing. It's
possible to go on with the first two packaging variants.
Anyway, I couldn't find the scripts in your packages.
> > 4.1. Building Embedded Programs
> > ---
> >
> > Programs which embed a Python interpreter must declare a
> > `Build-Depends' on `python.-dev'.
>
> Extension modules should do this as well.
Probably an extra section fo
