Re: Python upgrade path (draft/proposal)
Quoting Matthias Klose <doko@cs.tu-berlin.de>:
> 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.
>
> First proposal:
I think you need to clarify where we are going before we can decide how to get
there. I disagree slightly with your two a), b) options for package mantainers.
I think package mantainers have the following options;
Note, in the following I will assume the default python is python1.5-base.
a) Support only the default version. Name your package
python-XXX (for a library). Make your package depend on
python-base (>= 1.5), python-base (<< 1.6). Install you modules
into /usr/lib/python1.5/. Note that this means your package will break when
python-base is upgraded, and will not work for even old versions of
pythonX.Y-base.
b) Support a particular version(s) of python. Make your package depend on
pythonX.Y-base. It should install modules somewhere inside
/usr/lib/pythonX.Y/, and use "#!/usr/bin/pythonX.Y" for programs. A
recomended name would be pythonX.Y-<module>, as this allows you to add
packages to support other versions later on, but this is not required.
c) Support all/most versions of python, including the default. There are two
cases here;
1) You have extensions compiled against particular versions or python.
Create multiple pythonX.Y-<module> packages as in b). Also create an empty
package python-<module> with "Depends: python-base (>=1.5),
python-base (<<1.6), python1.5-<module>". The python-<module> package will
need to be updated to match python-base when ever it updates.
2) You have version independant python scripts/programs.
Create a single package that depends on python-base. Any name can be used,
but python-<module> is recomended for a library. It should install modules
somewhere inside /usr/lib/python/ and use "#!/usr/bin/python" for programs.
The postinst script should create symlinks in all /usr/lib/pythonX.Y/
directories that point to its /usr/lib/python/ files and compile them.
Note that if you choose b) you can support multiple versions if you wish, but
anyone using your module will be tied to whatever version you have chosen, and
must use "Depends: pythonX.Y-base, pythonX.Y-<yourmodule>", even if they are
using version independant python code. If you choose c), you are not required
to support all versions of python, as long as you support at least the default
selected by python-base. Option a) should be discoraged, as it in some ways
just a high mantainence version of b) or c).
It would be nice if python-base could provide the script to create symlinks and
compile modules for option c)2). Note that this action would also need to be
performed every time a new pythonX.Y-base package is installed, so it makes
sense to have a common script that all python modules can call in their post-
inst. The psedo code for such a script would be;
for dir in /usr/lib/python*.*; do
version=`echo $dir | sed "s/^.*python//"`
cp -Rsu /usr/lib/python/* $dir
<compile all in $dir using /usr/bin/python$version>
done
Now that I think about this, putting this script in python-base is probably a
bad idea, as it makes all the pythonX.Y-base depend on python-base. Probably a
better idea would be to have pythonX.Y-base provide a script that creates and
compiles the links for pythonX.Y only, and have python-base provide a script
that calls these scripts for all the installed pythonX.Y-base's. Options
abound :-).
> 1) File bug reports against existing python-XXX modules/packages,
> which do not have a dependency of the form:
> Depends: python-base (>= 1.5,2), python-base (<< 1.6)
Given my slightly different target objective above, this becomes "file bugs
against any packages that do not meet the above alternatives for packages".
> 2) Remove the python alternative from the current pyton-base
> package. The python-base (1.5.2) package provides the
> symlink to python1.5.
Yep.
> 3) Change the description of the python-XXX (1.5.2) packages
> "Package providing Debian's default version of the python-XXX
> package" (a proposal for a package description would be
> welcome).
> Make the python-XXX (1.5.2) packages depend on python1.5-XXX.
yep.
> Upload the packages with modifications from 2) and 3)
>
> 4) Wait until all/most bug reports filed in 1) are resolved.
yep. Note that during this transition, python1.5 is the default, so all
packages should be fixed to match the above scheme where python1.5 is the
default. At this point we have transitioned to the new scheme. The next part is
using this scheme to transition from 1.5 to 2.1.
> 5) Upload python core packages python-XXX (2.1) & Co depending
> on python2.1-XXX.
> Alternatively if python2.2 is released at this time we could
> go on with python2.2 from this point.
yep. Note that this act will break the dependancys of all the packages that
have "Depends: python-base (>=1.5), python-base (<<1.6)". This is intentional,
as all the packages with this dependancy will need upgrading.
> 6) At this point other python modules/packages can be made, which
> depend on python-base (>= 2.1), python-base (<< 2.2).
> Don't build 2.0 and 2.1 packages from the same source package
> (see 7).
[...]
Change this as described in the options above.
> 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.
yep.. fair enough, though I would hope that a mantainer who chooses a) or b)
would reconsider and change to c) if there was enough demand.
> 7) File reports that python2.0 should go away, file serious reports
> against all the python2-* the packages and ftp.debian.org.
either make python2.0 go away, or make it comply with the new scheme. Probably
go away is easier.
> Second proposal:
[...]
This was the same as above, except making 2.1 the default immediately, rather
than going to 1.5 first. The big difference is all the existing packages that
depend on just python or python-base and install into /usr/lib/python1.5 will
break, with no warning from dependancy checking. The solution is NMU update
these packages to comply with the new scheme. Probably the easiest way to do
this is to make them option b) compliant by changing their dependancies to
python1.5-base instead of python or python-base, and making sure they
use "#!/usr/bin/python1.5"
> The second proposal could be finished by the end of October (as far as
> I can estimate), so this should be ok for a woody release.
If proposal 1) can't be ready by woody, then it could still be released with
woody at the python1.5 = default stage, before step 5). In some ways this might
be faster than Option2, because it breaks less things. However, it would leave
woody with python1.5 as the default...
--
ABO: finger abo@minkirri.apana.org.au for more information.
Reply to: