On Sun, Oct 14, 2001 at 10:57:25AM +0200, Matthias Klose wrote:
> Jérôme Marant writes:
> > What about proposal and policy from Neil and his efforts?
> - the proposed packaging scheme doesn't allow smooth upgrades between
> one python version and a next version. compare python-1.5 to libc5
> and python-2.1 to libc6.
Supporting partial upgrades and supporting smooth upgrades are different
things. Also, in the above situation you'll note all the lib*g and
-altdev packages we were forced to have.
] 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>
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.
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.
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).
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
"Security here. Yes, maam. Yes. Groucho glasses. Yes, we're on it.
C'mon, guys. Somebody gave an aardvark a nose-cut: somebody who
can't deal with deconstructionist humor. Code Blue."
-- Mike Hoye,
see http://azure.humbug.org.au/~aj/armadillos.txt
Attachment:
pgpyTHQSPWqx8.pgp
Description: PGP signature