Anthony Towns writes: > 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).
I would prefer the former. It provides a basic python for packages that cannot be upgraded. > > 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. I agree on this interpretation of canonical version. > > 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? I really don't care why they ended there. It's legitimate for a package maintainer not to diverge from the upstream version and stay with an old version. > 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. we agree. (and there could be newer versions, which cannot be made the "normal" version soon enough). > So if you go "apt-get install python" you end up with python 2.0 (say), say 2.1 and we agree. > 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: [well explaining example removed] > That's how I thought Matthias' last proposal would work anyway (well, > with python-base not python anyway). So you did understand me correctly, perhaps you could reword the policy proposal, where I am unclear (hint, hint, ... ;-) And even the python-base -> python substitution sounds ok, now that we know that 100 conflicts on a line are a bad idea. Matthias Btw, where can I find python-apt ;-)