Re: Debian Python policy & Upgrade Path (draft/proposal)
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-<X>.<Y>' and include the file
> > `/usr/bin/python<X>.<Y>'.
>
> Here you have "python-<X>.<Y>" and elsewhere you have "python<X>.<Y>".
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<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
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
<compile all in $dir using /usr/bin/python$version>
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-<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.
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<X>.<Y>-dev'.
>
> Extension modules should do this as well.
Probably an extra section for build dependencies? Now I included a
paragraph about build-depends in each packaging variant.
> > A. Upgrade Procedure
> > --------------------
> > 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 couldn't find these source diffs on people.debian.org.
Probably we should allow NMUs which only fix the dependencies?
> 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.
It seems the python maintainer (no s) is still busy/asleep (Gregor?).
Probably we can find another volunteer, who could convert/patch the
packages. Do you have a list of these packages?
> Now, new packages have been installed into woody. Hmm.
Currently in unstable (sid). But I hope they go to woody soon.
Matthias
Debian Python Policy
--------------------
Neil Schemenauer <nas@debian.org>
Matthias Klose <doko@debian.org>
version 0.3.1
-------------------------------------------------------------------------------
Abstract
--------
This document describes the packaging of Python within the Debian
GNU/Linux distribution and the policy requirements for packaged Python
programs and modules.
Copyright Notice
----------------
Copyright (C) 1999, 2001 Software in the Public Interest
This manual is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the
Free Software Foundation; either version 2 of the License, or (at your
option) any later version.
This is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
for more details.
A copy of the GNU General Public License is available as
`/usr/share/common-licences/GPL' in the Debian GNU/Linux distribution
or on the World Wide Web at The GNU Public Licence
(http://www.gnu.org/copyleft/gpl.html).
You can also obtain it by writing to the Free Software Foundation,
Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
-------------------------------------------------------------------------------
Contents
--------
1. Python Packaging
1.1. Stable and Legacy Versions
1.2. Base Package
1.3. Module Path
1.4. Documentation
2. Packaged Modules
2.1. Support Only The Default Version
2.2. Support a Particular Version(s)
2.3. Support All/Most Versions (Including Default)
2.4. Dependencies
2.5. Module Package Names
3. Python Programs
3.1. Version Independant Programs
3.2. Version Dependant Programs
4. Programs Embedding Python
4.1. Building Embedded Programs
4.2. Embedded Python Dependencies
A. Upgrade Procedure
-------------------------------------------------------------------------------
1. Python Packaging
-------------------
1.1. Stable and Legacy Versions
-------------------------------
At any given time, the package `python-base' should represent the
latest stable upstream version of Python, that Debian is able to get
into the release.
Only one package may contain the `/usr/bin/python' binary and that
package must either be `python-base' or a dependency of that package.
The `python' package must provide `python<X>.<Y>'; where <X> and <Y>
represent the major and minor versions of the Python, respectively.
There can be any number of legacy Python packages available. These
must be named `python<X>.<Y>-base' and include the file
`/usr/bin/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 Python to be installed,
the `python-base' package contains the binary and a basic set of
modules.
1.3. Module Path
----------------
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/python<X>.<Y>/site-packages
/usr/local/lib/site-python
/usr/lib/python<X>.<Y>/site-packages
1.4. Documentation
------------------
Python documentation is split out in separate packages
`python<X>.<Y>-doc'. The package `python-doc' depends on the
`python<X>.<Y>-doc' (the documentation of the current stable upstream
version of Python.
TODO: Policy for documentation of third party packages.
-------------------------------------------------------------------------------
2. Packaged Modules
-------------------
There is more than one way to package a Python module:
1. Support only the default version.
2. Support a particular version, or some but not all versions of
Python available in Debian.
3. Support all/most versions of python, including the default.
Works only for architecture independant python modules. NOT YET
SUPPORTED!!!
2.1. Support Only The Default Version
-------------------------------------
Name your package `python-foo' (for a library). Make your package
depend on `python-base (>= <X>.<Y>)', `python-base (<< <X2>.<Y2>)'.
Install you modules into `/usr/lib/python<X>.<Y>/'. Note that this
means your package will break when `python-base' is upgraded, and will
not work for even old versions of `python<X>.<Y>-base'.
The packaged source must declare a `Build-Depends' on
`python<X>.<Y>-dev', where <X>.<Y> is the default version.
2.2. Support a Particular Version(s)
------------------------------------
Make your package depend on `python<X>.<Y>-base'. It should install
modules somewhere inside `/usr/lib/python<X>.<Y>/', and use
`#!/usr/bin/pythonX.Y' for programs. A recomended name would be
`python<X>.<Y>-foo', as this allows you to add packages to support
other versions later on, but this is not required.
The packaged source must declare a `Build-Depends' on
`python<X>.<Y>-dev', where <X>.<Y> is the version chosen by the
package maintainer.
2.3. Support All/Most Versions (Including Default)
--------------------------------------------------
This option is available for architecture independent packages. XXX
Not yet supported!!! There are two cases:
1. You have extensions compiled against particular versions or
Python. Create multiple `python<X>.<Y>-<module>' packages as in
Section 2.2, `Support a Particular Version(s)'. Also create an
empty package `python-<module>' with
Depends: python-base (>= X.Y), python-base (<< X2.Y2), pythonX.Y-module
The `python-<module>' package will need to be updated to match
python-base when ever it updates.
The packaged source must declare `Build-Depends' on each
`python<X>.<Y>-dev' package, the module is built for (i.e.
building more than one Python version from the same source).
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.
The packaged source must declare `Build-Depends' on one
`python<X>.<Y>-dev' package. XXX: Or build-depend on each Python
version, so that only checked modules are uploaded?
2.4. Dependencies
-----------------
Packaged modules must depend on `python-base (> <X>.<Y>)' and
`python-base (<< <X2>.<Y2>)'.
2.5. Module Package Names
-------------------------
Python module packages should be named for the primary module
provided. The naming convention for module `foo' is `python-foo'.
Packages which include multiple modules may additionally include
provides for those modules using the same convention.
Python module packages packaged for one particular version of Python
should be named `python<X>.<Y>-foo'.
-------------------------------------------------------------------------------
3. Python Programs
------------------
3.1. Version Independant Programs
---------------------------------
Programs that can run with any version of Python must start with
`#!/usr/bin/python'. They must also specify a dependency on
`python-base'.
3.2. Version Dependant Programs
-------------------------------
Programs which require a specific version of Python must start with
`#!/usr/bin/python<X>.<Y>'. They must also specify a dependency on
`python<X>.<Y>'.
-------------------------------------------------------------------------------
4. Programs Embedding Python
----------------------------
4.1. Building Embedded Programs
-------------------------------
Programs which embed a Python interpreter must declare a
`Build-Depends' on `python<X>.<Y>-dev'.
4.2. Embedded Python Dependencies
---------------------------------
Dependencies for programs linking against the shared Python library
will be automatically created by `dpkg-shlibdeps'.
-------------------------------------------------------------------------------
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. XXX Do we allow NMUs which only fix
the dependencies?
2. Remove the python alternative from the current `python-base'
package. The `python-base (1.5.2)' package provides the symlink
to `python1.5'.
3. Change the description of the `python-<module> (1.5.2)' packages
to "Package providing Debian's default version of the
`python-<module>' package". Make the `python-<module> (1.5.2)'
packages depend on `python1.5-<module>>'.
4. Wait until all/most bug reports filed in 1) are resolved. Note
that during this transition, `python1.5' is the default, so all
packages should be fixed to match the above scheme where
`python1.5' is the default. At this point we have transitioned
to the new scheme. The next part is using this scheme to
transition from 1.5 to 2.1.
5. Upload python core packages `python-<module> (2.1)' & Co
depending on `python2.1-<module>'. Alternatively if `python2.2'
is released at this time we could go on with `python2.2' from
this point.
Note that this act will break the dependencies of all the
packages that have
Depends: python-base (>=1.5), python-base (<<1.6)
This is intentional, as all the packages with this dependancy
will need upgrading.
6. At this point other python modules/packages can be made, which
follow the policy from XXX.
If maintainer A (maintaining `python-foo' (depending on
`python-base (>= 2.1)', `python-base (<< 2.2))' decides for (a),
then a maintainer B should be allowed to repackage
`python1.5-foo', if "his" package cannot be converted to use the
default Python version.
7. File reports that `python2.0' should go away, file serious
reports against all the `python2-*' the packages and
`ftp.debian.org'.
8. Hopefully release woody with `python2.1' or better as the default
Python version.
-------------------------------------------------------------------------------
Debian Python Policy
Neil Schemenauer <nas@debian.org>
Matthias Klose <doko@debian.org>
version 0.3.1
Reply to: