MIR for basic python3 stack
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| distribute (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
| python-bsddb3 (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
| python3-defaults (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
| python3.1 (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bug Description
Binary package hint: python3.1
the obvious reason for this is the b-d of distribute on python3, now building a python3-
- python3.1, same packaging/
- python3-defaults, same packaging/
- distribute (new binaries for python3)
- python-bsddb3 (new binaries for python3); I would like to see this module in main, because python3 did drop
the bsddb module from the core library. it's included in main in an older version in the python2.6 core
library.
The rationale for a separate python3 stack was given in http://
"""
Packaging for Python 3.x
-------
Python 3.x is not upward compatible to 2.x and requires changes to the
sources. Almost no file can be used unmodified. A large part of the
changes can be done automatically with the help of the 2to3 utility.
Porting resources can be found at
- http://
- http://
- http://
Upstream does expect Python-2.x to stay around for a while; Python-3.x
will need some time until extensions and modules are ported. For this
reason I do plan to have both Python-2.x and Python-3.x in the next
stable Debian release.
Some third party modules and extensions may be released in a form
where the code for 3.x can be auto-generated from the 2.x code with
the 2to3 utility, some upstreams may decide to stop 2.x support with
one version and provide 3.x support with another version. Debian has
to support both approaches. The currently used packaging methods only
allow packaging of one version for all Python version (installing in a
shared area and providing this version for each Python version).
Binary packages will double in size when providing both 2.x and 3.x
compatible code, so it does make sense to provide separate binary
packages for 2.x and 3.x. These new packages should be prefixed with
`python3-' instead of `python-'. It's up to the package maintainer if
these packages are built from one or two source packages.
There will be a `python3' package and similiar packages built out of a
python3-defaults, which will provide the `python3' binary.
"""
| Michael Vogt (mvo) wrote | #1 |
| Martin Pitt (pitti) wrote | #2 |
| Changed in distribute (Ubuntu): | |
| status: | New → Invalid |
| Martin Pitt (pitti) wrote | #3 |
| Changed in python3-defaults (Ubuntu): | |
| status: | New → Fix Committed |
| Martin Pitt (pitti) wrote | #4 |
| Changed in python3.1 (Ubuntu): | |
| status: | New → Fix Committed |
| Martin Pitt (pitti) wrote | #5 |
| Changed in python-bsddb3 (Ubuntu): | |
| status: | New → Fix Committed |
| Matthias Klose (doko) wrote | #6 |
| Steve Langasek (vorlon) wrote | #7 |
| Changed in python3.1 (Ubuntu): | |
| status: | Fix Committed → Fix Released |
| Steve Langasek (vorlon) wrote | #8 |
| Changed in python3-defaults (Ubuntu): | |
| status: | Fix Committed → Fix Released |
| Steve Langasek (vorlon) wrote | #9 |
| Changed in python-bsddb3 (Ubuntu): | |
| status: | Fix Committed → Fix Released |
Having python3.1 in main also has the very nice benefit that python-apt will build against it we can provide the python-apt stack in lucid for python3. I imagine this will make the next LTS release upgrade much simpler. By that time I except that python3 will be used for update-manager so having the libs/stack availalbe will be a win.