Re: Python 2.0.1; transition plans for woody
On Tue, Jun 26, 2001 at 12:47:28AM +1000, Anthony Towns wrote:
> On Mon, Jun 25, 2001 at 04:36:28PM +0200, Gregor Hoffleit wrote:
> > This would mean that I upload new versions of the Python packages:
> > (1) python2 (python2-base etc.) would be removed
> > (2) python 2.0.1-1 (python-base etc.) would replace python 1.5.2-16
> > (3) A new set of legacy packages python15 (python152 ???) for those who
> > think that they depend on the old version 1.5.2.
> > The transition would not be simple, though.
>
> How does this affect upgrades?
>
> Will potato packages that depend on python work with python 2.0.1 packages
> in general? What about ones that put stuff in /usr/lib/python1.5? If not,
> what will you do to ensure partial upgrades work correctly? If so, that may
> give us an easy out for transitioning the python2 packages.
We have an option here:
With the default setup, stuff in /usr/lib/python1.5/site-packages would be
ignored by 2.0.1. In order to make the transition easier, we might decide to
append /usr/lib/python1.5/site-packages to the sys.path, though:
Almost all pure Python modules that are currently installed in the python1.5
directory will work with 2.0.1; Python 2.0.1 is almost completely backwards
compatible, and one might consider all remaining problems bugs in the potato
packages.
Binary modules in /usr/lib/python1.5/site-packages won't work.
> > Nearly all Python packages (to be exact: those who install things in
> > /usr/lib/python1.5, those who build binary extension modules, and those who
> > link with libpython1.5) would have to be modified and rebuilt. Those
> > packages that provide both python2-* and python-* versions would have to be
> > modified to instead build python-* and python15-* versions; the dependencies
> > of those packages would need closer inspection.
>
> There are only a dozen or so packages in unstable/i386 that have versioned
> depends on python2 related stuff; anything else should be able to be
> handled with provides:.
IMHO that's the most pressing problem, and has to be inspected carefully:
Packages that have unversioned depends on python or python-base, but do in
fact depend on Python 1.5.2. They would break after an upgrade to
> > What do you think ?
>
> If you can make upgrades work; if you can not break too many
> people's testing or unstable systems; and if you can get everything
> rewritten/rebuilt relatively quickly, I'd say it's worth doing.
A first try at an transition plan:
(1) I upload python 2.0.1-1. python-base 2.0.1-1 provides 'python', 'python2'
and 'python2-base'. /usr/lib/python1.5/site-packages will be appended to the
sys.path. A bug will be filed against the archive to remove the python2
package.
Most 'python-*' packages will continue to work in this setup. python2-*
packages should continue to work as well. python-* Packages with binary
extension modules will break.
(2) python-* packages that broke should be rebuilt against the Python 2.0.1
package as fast as possible. Aggressive NMUs should be allowed here after a
few days.
(3) Bugs should be filed against all remaining packages that install stuff
in /usr/lib/python1.5. They should be rebuilt against Python 2.0.1. Finally,
no woody package should install stuff in /usr/lib/python1.5.
I'm pretty sure that I miss some crucial points with this plan, though.
Please correct me where due.
My impression is that during a transition period, unstable's Python packages
will be quite unstable. Still, rebuilding the packages should be a very
simple thing in most cases, so the only crucial thing is that either
maintainer act quickly, or we're going on NMU aggressively.
One remaining problem is how to handle partial upgrades of a potato system:
To handle this well, python-base 2.0.1-1 would have to include a list of
conflicts against all potato packages that won't work with the new python
packages (I guess in the end that's about a dozen packages).
Gregor
Reply to: