With the last python-1.5.2-18.2 NMU we have non-conflicting python1.5,
2.0 and 2.1 packages in unstable, not more not less.
Here two proposals, how to go further on. The first proposal is a
safer proposal (but needs more uploads and needs loong). The second
proposal accepts some breakage during the upgrade, but is a bit
shorter.
First proposal:
1) File bug reports against existing python-XXX modules/packages,
which do not have a dependency of the form:
Depends: python-base (>= 1.5,2), python-base (<< 1.6)
2) Remove the python alternative from the current pyton-base
package. The python-base (1.5.2) package provides the
symlink to python1.5.
3) Change the description of the python-XXX (1.5.2) packages
"Package providing Debian's default version of the python-XXX
package" (a proposal for a package description would be
welcome).
Make the python-XXX (1.5.2) packages depend on python1.5-XXX.
Upload the packages with modifications from 2) and 3)
4) Wait until all/most bug reports filed in 1) are resolved.
5) Upload python core packages python-XXX (2.1) & Co depending
on python2.1-XXX.
Alternatively if python2.2 is released at this time we could
go on with python2.2 from this point.
6) At this point other python modules/packages can be made, which
depend on python-base (>= 2.1), python-base (<< 2.2).
Don't build 2.0 and 2.1 packages from the same source package
(see 7).
Each package maintainer should decide, if he only supports the
default python version, or more than one version (the policy
should make this clear).
a) support the default version only: Name your package
python-XXX (for a library). Make your package depend on
python-base (>= 2.1), python-base (<< 2.2).
b) support more than one python version: Make packages
python1.5-XXX and python2.1-XXX and a package python-XXX.
The python1.5-XXX and python2.1-XXX packages should depend
on python1.5-base and python2.1-base, the python-XXX
package should depend on of of the python1.5-XXX or
python2.1-XXX packages.
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.
Second proposal:
1) Remove the python alternative from the current pyton-base
package. The python-base (2.1) package provides the
symlink to python2.1.
2) Change the description of the python-XXX (2.1) packages
"Package providing Debian's default version of the python-XXX
package" (a proposal for a package description would be
welcome).
Make the python-XXX (2.1) packages depend on python2.1-XXX.
3) Upload python core packages python-XXX (2.1) & Co depending
on python2.1-XXX.
Alternatively if python2.2 is released at this time we could
go on with python2.2 from this point.
4) Packages not compatible with python2 need to be uploaded
to use the python1.5 packages/binary. NMU's should be allowed
to fix these ...
5) At this point other python modules/packages can be made, which
depend on python-base (>= 2.1), python-base (<< 2.2).
Don't build 2.0 and 2.1 packages from the same source package
(see 7).
Each package maintainer should decide, if he only supports the
default python version, or more than one version (the policy
should make this clear).
a) support the default version only: Name your package
python-XXX (for a library). Make your package depend on
python-base (>= 2.1), python-base (<< 2.2).
b) support more than one python version: Make packages
python1.5-XXX and python2.1-XXX and a package python-XXX.
The python1.5-XXX and python2.1-XXX packages should depend
on python1.5-base and python2.1-base, the python-XXX
package should depend on of of the python1.5-XXX or
python2.1-XXX packages.
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.
6) File reports that python2.0 should go away, file serious reports
against all the python2-* the packages and ftp.debian.org.
The second proposal could be finished by the end of October (as far as
I can estimate), so this should be ok for a woody release.
Hope that Neil _and_ Gregor (re)join the discussion.
Matthias
