Re: What should we do now?
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 ;-)
Reply to: