Re: Status report on python2 transition
On Jul 04, Gregor Hoffleit wrote:
> First of all the good news: You have managed to talk me into making the
> big step, and going right to the 2.1.1 CVS branch. Thomas Wouters
> (release czar for Python 2.1.1) assured me that 2.1.1 will be released
> before the freeze, and Guido heavily supported that.
That is good news.
> Now for the bad news: I don't have any conclusive plan how to manage
> transitions for future Python feature releases, like 2.2, 2.3 and so on.
>
> Until now I had the impression that in general it's not necessary to
> have more than one Python version on your machine at the same time
> (except perhaps you're a Python core developer). Feedback from
> python-dev though was that it's definitely necessary to allow and
> support multiple concurrent versions of Python even on production
> machines.
>
> If we're going to support this in Debian regularly, then it get's even
> much more complicated than with our current setup of python-* and
> python2-*.
>
> Please have a look at the python-dev archives for the full discussions:
> http://mail.python.org/pipermail/python-dev/2001-July/015715.html
My semi-well-thought-out solution:
- python-* should provide a "Standard" Python for each Debian
release. 2.1.1 seems a sensible target for woody. These packages
should be invoked by /usr/bin/python and /usr/bin/pythonx.y
- python-* should (virtual) provide python-x.y-*.
- python-v.w-* (where v.w != x.y) can exist at the discretion of the
Python maintainer. Provides /usr/bin/pythonv.w
I recommend at least having 1.5.2 in woody. 2.0.1 may also be
useful. I don't see any good reason for us to ship 1.6.1.
- The complete version number of Python should appear in the version
field. I recommend using X.Y(.Z)?[abcfp](N?)-rev; this also complies with
Debian's sort order. .Z and N can be omitted if 0. However, f is
mandatory for a final release, to maintain sort order.
(Packages built from CVS could be 2.2a-2001xxxx.)
- Packages that don't care what Python is installed can depend on
python-*. Most simple Python packages fit here. If any features
used are deprecated in the most recent X.Y release, they can depend
on python-* (<< X.Y+1). They can use #!/usr/bin/python.
- Packages that provide Python-language library modules:
- Depend on python-v.w-* | python-y.z-* | ... for all versions they
can run on.
- Provide /usr/lib/pythonX.Y/site-packages/... for all versions they
can run on; I'd use symlinks if the code needn't change.
- Invoke compileall.py for each version available.
- Run python-wrapper-config * in postinst and postrm.
- Packages that provide binary-linked library modules:
- Depend on python-v.w-* | python-y.z-* | ... for all versions they
can run on.
- Build-depend on python-v.w-*, python-y.z-*, ... for all versions
they can run on.
- Provide /usr/lib/pythonX.Y/site-packages/... for all versions they
can run on.
- If two releases share the same API version, the same binaries may be
shared in site-packages. (Not sure if this happens in practice.)
- Follow the above policy with regards to any Python-language
modules.
- Run python-wrapper-config * in postinst and postrm.
- Python packages that need particular modules: This is sticky.
- Depend on the needed packages to provide the modules.
- Depend on python-* (>= X.Y) if it uses features unique to X.Y+
- In postinst, figure out the python-x.y packages that are
installed and provide all necessary modules and fulfill the
dependencies for this package. Write this to a file.
(This is handled by "python-wrapper-config" *)
We need to register each package that cares about this in
a file (/var/lib/python/needs-wrapper *) for module postinst/rm.
We are guaranteed to have at least one Python version that works
if one module is involved by dependencies. If multiple modules
are involved, we may have zero working versions (which is a bug)
and will be detected by this step, causing package install to fail.
How to do this:
- Executables use #!/usr/bin/python-wrapper (*)
- Have a file /var/lib/python/wrapper-config (*) with
executable: version1, version2, ...
This is written by the postinst.
- Have a python-wrapper that reads $1, figures out which executable is
involved, and invokes the appropriate python. (It can probably
be in Python itself... perhaps provided by python-x.y-base and
managed by alternatives.)
- This "figuring out" will have to be done by each python-x.y-*
and each modules package on install and remove too.
- Remove this cruft in the postrm.
(*) Rename this to something better if you like.
The main disadvantage is that people compiling binary-linked library
modules will need multiple Pythons installed; of course, unless some
magic API fix comes along, they would anyway.
It also doesn't include any way to accomodate locally-built Pythons,
unless they are built and installed as debs. This may or may not be a
problem (some people may want to track CVS).
I think this covers all of the important issues though. It may be
needlessly complex, but it does support users having whatever Pythons
they want installed and should allow most things to work.
Chris
--
Chris Lawrence <lawrencc@debian.org> - http://www.lordsutch.com/chris/
Reply to: