On Tue, Oct 23, 2001 at 06:13:31PM +0200, Gregor Hoffleit wrote: > > > Regarding (1): If you ask me how common the situation is that people > > > install local Python versions in /usr/local, then I will ask you how > > > common it is that it's reasonable that a script provided by a Debian > > > package will benefit from using #!/usr/bin/env ? > > Well, how about you answer the question instead? > Certainly that's not a fair statistic,
Uh, I meant the question I asked. :) But anyway... > Just to make sure we have the same thing in mind: At this point, > python-base is no virtual package provided by some real pythonX.Y-base > package, but it's a real package, right ? Right. This could be done as either: python-base 1.5.1 Depends: python1.5-base 1.5.1 (a dummy package just containing some docs and the /usr/bin/python link) or python-base 1.5.1 Provides: python1.5-base depending on how you wanted to maintain it. (The former would make it easy to keep 1.5 packages around when you move to 2.x, the latter would have less dummy packages). > This would work indeed, provided a single, canonical Python version was > an option (see below). I don't think it's reasonable to have anything but a single canonical Python version; although clearly I was too dismissive of having extra versions handy. > Sorry, but maintaining a single canonical version of Python in the > distribution won't work. All this means is that on all woody systems, /usr/bin/python is the same version of python, and that any packages that don't use that version need a damn good reason for it. > That's not my opinion, that's what the Python > developers crew at python-dev told me. > Until recently, Mailman didn't work with Python >> 1.5.2. Zope 2.2 > didn't work with Python >> 1.5.2. Zope 2.4 doesn't work with Python << > 2.1. How did mailman and zope manage to end up like this? From the python.org pages, the only backwards incompatibilities were a couple of things about changes in arguments, that seem trivially fixable? In any event, I *think* we're in violent agreement here: there ought to be old versions in the archive that you can declare a dependency on, get other modules for, and set as your interpretor; but there also ought to be a single /usr/bin/python in any release that's used by every "normal" package. So if you go "apt-get install python" you end up with python 2.0 (say), and if you follow that up by "apt-get install zope", you still have python 2.0 for everything normal, but you also get python 1.5 (and any necessary python 1.5 modules) in some out of the way place for zope's use. Which would be something like: python 2.0.1-1 Depends: python2.0 python2.0 2.0.1-1 python-apt Provides: python2.0-apt Depends: python (>= 2.0), python (<< 2.1) dak Depends: python, python-apt, apt-utils Description: Debian archive maintainance scripts python1.5 python1.5-ldap Depends: python1.5 zope Depends: python1.5 zope-ldap Depends: zope, python1.5-ldap The scripts in dak could then use #!/usr/bin/env python (which happens to be what it uses now) and rely on the modules they import being installed and versioned correctly, meanwhile zope can use #!/usr/bin/python1.5 and similarly work okay. If python 2.1 gets packaged, the modules all need to be rebuilt and repackaged, but dak.deb will just keep working quite happily. If python 2.2 comes out and breaks dak, well that's its fault, and it could've been avoided if the dak maintainer cared by having a "python (<< 2.1)" dependency, which would've needed to have been updated when 2.1 came out. You could also have, say: python-ldap Depends: python (>= 2.0), python (<< 2.0), python2.0-ldap python2.0-ldap Depends: python2.0 if you wanted to maintain python-ldap in a way that makes it easier to keep older versions in the archive (as compared to python-apt, which would need to be repackaged more carefully). That's how I thought Matthias' last proposal would work anyway (well, with python-base not python anyway). Cheers, aj -- Anthony Towns <[EMAIL PROTECTED]> <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
pgpvvViH3Avou.pgp
Description: PGP signature