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 <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:
pgp7I0HH_lIlw.pgp
Description: PGP signature