Re: Python upgrade path (draft/proposal)
On Oct 17, Matthias Klose wrote:
> 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.
[...]
> 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.
May I suggest a simpler alternative for (b) (or maybe an alternative "c"):
Make package python-XXX containing support for both python 1.5 and
python 2.1. For each python {1.5,2.1} that is installed, bytecompile
the package's .py files on install. Since we use
/usr/lib/pythonx.y/site-packages, it won't hurt anything if the
"other" version is not installed. If the files are identical, they
should only appear in the package once (use hard links or symlinks,
but don't symlink directories because of .py[co]). Depend on
python-base (>= 1.5.2-1) and nothing should break. Build-depend on
both python1.5-base and python2.1-base.
Since the buildds need both versions installed to make
python{2.1,1.5}-X anyway, this approach doesn't cause them any extra
problems.
The only downside is that people with one installed python will get
extra cruft installed, but the use of links should minimize it. I'd
follow this alternative unless the package consists entirely of .so
files and the .so files are *big*.
I can build a new python-pqueue as an example if anyone wants to see
how this might work in practice...
Chris
--
Chris Lawrence <cnlawren@olemiss.edu> - http://www.lordsutch.com/chris/
Instructor and Doctoral Student, Political Science, Univ. of Mississippi
208 Deupree Hall - 662-915-5765
Reply to: