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 <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/