Anthony Towns writes:
> ] python-2.1_2.1.1
> ] python_2.1.1 (depends on python-2.1) (does "ln /usr/bin/python{2.1,}")
> ] python-2.1-<module>_<version> (depends on python-2.1)
> ] python-<module>_<version> (depends on python and python-2.1-<module>)
>
> Hrm. That should be:
>
> Package: python-<module>
> Version: <version>
> Depends: python (>= 2.1), python (<< 2.2), python-2.1-<module>
>
> The versioned deps are important. Actually, the versioning is a bit more
> complicated too, and would need to be:
>
> Version: <python-version>+<module-version>
And for a zope module <python-version>+<zope-version>+<module-version> ;-?
> or something similar, to ensure upgrades work right. Although you might be
> able to get away with:
>
> Version: <upstream-module-ver>-2.1-<debian-revision>
>
> ] <python program>_<version> (depends on python and python-<module>,
> ] #!/usr/bin/python)
> ] <python program>-2.1_<version> (depends on python-2.1 and
> ] python-2.1-<module>, #!/usr/bin/python2.1)
>
> > there was a clear upgrade procedure to do
> > the transition. The proposed packaging scheme doesn't allow such an
> > upgrade. From my point of view, this is a showstopper.
>
> The transition to python_2.2.1 (say), in the above would seem to be to
> rebuild all of the python module's against 2.2, and upload them. When
> they're all uploaded (or all the ones you use are uploaded), you can
> upgrade python.dev, and python-<module>.deb all at once, and you'll go
> from a consistently 2.1-based system to a consistently 2.2-based system.
For my understanding:
- we do have versioned packages for each package, which is built from
the pythonX.Y package:
python1.5-base python2.1-base
python1.5-tk python2.1-tk
python1.5-gdbm python2.1-gdbm
... ...
- If a module is provided as a versioned package, then there must be
an unversioned package as well, which depends on the most recent
working version of the versioned package.
So we will have at least python-tk, python-gdbm, etc ...
Same for python-base and python-dev.
Versioned "third party" modules are needed, if different
versions of the modules are needed (i.e numpy-20 doesn't work
with python1.5, only numpy-17 does).
> There aren't really any better scenarios if you can only use 2.1-based
> modules with python 2.1, and 2.2-based modules with python 2.2. In
> particular, this is ensured simply by having the right dependencies. You
> could maybe have some scripts that use python2.1 and python2.1 modules,
> and others that use python2.2 and python2.2 modules, but then you have
> to expect scripts to have the version of python they use hardcoded for
> no good reason, and things start getting pretty ugly.
>
> The proposed scheme also allows you to have different versions of python
> and its modules installed concurrently, although scripts from Debian
> will only ever use the version matching python.deb.
Assume I have installed
- python-dev (1.5.x), depending on python1.5-dev
- python-dev (2.1.x), depending on python2.1-dev
- python points to python1.5
- python-foo was just converted to depend on python (>=2.1, << 2.2).
- the new python-foo doesn't work with python1.5 anymore.
If the unversioned python binary is used in python-foo, then this
package won't work (assume I have to use the new python-foo to build a
new python-bar). I don't see how we can enforce this without calling
the versioned python binary in the python-foo package. And there's no
problem to replace the binary [1].
> It does have the bad property that it duplicates every module package,
> though. That's a trade off between whether you want to automatically
> support people running two different versions of python on the one machine
> or not, afaics, you either get one or the other (or you make it hard for
> people to refer to the packages at all, like Depends: python | python2 |
> python21 | python30 | ...; Provides: would stop you from being able to use
> dependencies to ensure your system is consistent).
well, a release should never ship with more than two
versions: The python version from the last release and a recent
version, so you have two support two dependencies.
you won't need to duplicate packages,
- if it's an arch independant package
- if the module version builds with both/all python versions
- if we have a mechanism how to to register/unregister a
module for different python versions.
But this is something which could be delayed after the woody release.
Matthias
[1]
cd debian && \
for i in `find -mindepth 2 -type f`; do \
sed '1s,#!.*python[^ ]*\(.*\),#! /usr/bin/python$(VER)\1,' \
$$i > $$i.temp; \
if cmp --quiet $$i $$i.temp; then \
rm -f $$i.temp; \
else \
mv -f $$i.temp $$i; \
chmod 755 $$i; \
echo "fixed interpreter: $$i"; \
fi; \
done
