On Tue, Oct 16, 2001 at 11:39:06PM +0200, Matthias Klose wrote:
> Anthony Towns writes:
> > ] 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>
> > Depends: python (>= 2.1), python (<< 2.2), python-2.1-<module>
> > ] <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)
> For my understanding:
> - we do have versioned packages for each package, which is built from
> the pythonX.Y package:
> python1.5-base python2.1-base
> python1.5-tk python2.1-tk
> python1.5-gdbm python2.1-gdbm
> ... ...
Right. And we also have python, python-base, python-tk, etc packages that
Depend: on whichever of python{1.5,2.1}-* is appropriate.
> - If a module is provided as a versioned package, then there must be
> an unversioned package as well, which depends on the most recent
> working version of the versioned package.
And also has a versioned dependency on python-base.deb.
> So we will have at least python-tk, python-gdbm, etc ...
> Same for python-base and python-dev.
Right.
> Versioned "third party" modules are needed, if different
> versions of the modules are needed (i.e numpy-20 doesn't work
> with python1.5, only numpy-17 does).
They're not *needed*, but they can be provided if there are users who would
find them useful.
> Assume I have installed
> - python-dev (1.5.x), depending on python1.5-dev
> - python-dev (2.1.x), depending on python2.1-dev
> - python points to python1.5
> - python-foo was just converted to depend on python (>=2.1, << 2.2).
> - the new python-foo doesn't work with python1.5 anymore.
In that case, you have, say:
python-base 1.5.1-16 (Depends: python-base1.5)
python-base 2.1.3-7 (Depends: python-base2.1)
python1.5-base 1.5.1-8
python2.1-base 2.1.3-12
python1.5-foo 1.8-9 (I think the version stuff I mentioned last
time was probably way off base)
python-foo 1.8-9 (Depends: python2.1-foo,
python-base (>= 1.5),
python-base (<< 1.6))
python2.1-foo 1.9-1 (I think the version stuff I mentioned last
time was probably way off base)
python-foo 1.9-1 (Depends: python2.1-foo,
python-base (>= 2.1),
python-base (<< 2.2))
> If the unversioned python binary is used in python-foo, then this
> package won't work (assume I have to use the new python-foo to build a
> new python-bar).
It's not quite clear what you mean there. If "python-foo" uses the
unversioned /usr/bin/python somehow, that's okay, since its dependencies
ensure that /usr/bin/python is the right version.
If it's python2.1-foo otoh, then that would be broken. It's not clear
to me why python2.1-foo would be referring to /usr/bin/python instead
of /usr/bin/python2.1 though. If this sort of thing actually happens,
then python-fooX.Y needs the >= and << python dependencies too.
That obviously stops you from having two versions of python-fooX.Y installed
at once though (since one expects /usr/bin/python to be one thing, and the
other expects it to be something else, and you can't satisfy both at once).
So you might as well just have a singly "python-foo" with versioned deps on
python-base.
> I don't see how we can enforce this without calling
> the versioned python binary in the python-foo package. And there's no
> problem to replace the binary [1].
It seems to me that this doesn't happen with most python modules. Only
13 of 428 files in my /usr/lib/python1.5 have a #! line, eg.
It's a different matter for packages containing scripts, rather than
modules. AIUI.
> well, a release should never ship with more than two
> versions: The python version from the last release and a recent
> version, so you have two support two dependencies.
TBH, it hasn't been explained to my satisfaction why we care about
providing the python version from the last release even.
As far as package maintenance is concerned, the above policy doesn't make
anything any easier: everything has to be rebuilt or it'll stop working.
The number of people who actually want to concurrently use python 1.5 and
python 2.1 (eg) on the same system doesn't seem particularly large to me.
And providing multiple versions of modules doesn't really make upgrades any
easier, either.
I'm happy to accept it as an article of faith, but I don't really grok it.
> you won't need to duplicate packages,
> - if it's an arch independant package
> - if the module version builds with both/all python versions
> - if we have a mechanism how to to register/unregister a
> module for different python versions.
If we have a mechanism to register/unregister a module for different
python versions (a la emacs) then we don't need to bother worrying about
the modules at all. It's not clear to me (as a relative python newbie)
whether this is possible or not.
That setup would basically be:
python Depends: python 2.1
python1.5 (postinst converts all modules on the system to work with
python1.5)
python2.1 (likewise)
python-foo (postinst sets foo up to work with all installed
version of python)
Packages that need a specific version of python as /usr/bin/python need
the same versioned deps on python as listed above (>= and <<).
The complexity would be in handling backwards compatibility issues in
python. Absolutely ensuring that a new version of python works with
all the modules you've got installed, and reporting any failures isn't
a trivial problem. Having either modules or scripts stop working with
new versions of python would screw up Depends: lines to some extent;
and it'd be difficult to handle them at all well (the python.deb would
have to have large Conflicts: lines to do it reliably, afaict). OTOH,
it'd work in almost all cases, and would be very easy to maintain in
the cases that work.
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
