Quoting Matthias Klose <[EMAIL PROTECTED]>:
> 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>
> > Version: <version>
> > Depends: python (>= 2.1), python (<< 2.2), python-2.1-<module>
> >
> > The versioned deps are important. Actually, the versioning is a bit
> more
> > complicated too, and would need to be:
> >
> > Version: <python-version>+<module-version>
>
> And for a zope module <python-version>+<zope-version>+<module-version>
> ;-?
[...]
Nah... it doesn't have to be that complicated unless you want it to be.
Remember python-<module> is just a wrapper package to provide a dependancy for
version-independant packages so they can have "Depends: python, python-
<module>" and be sure they use a compatible pair of pythonX.Y and pythonX.Y-
<module>. Anything that does rely on a particular version of python-<module>
should have "Depends: pythonX.Y-<module>". This means you can just use;
Version: <module-version>-<debian-revision>
Sure, at some point the default python will change from pointing at python1.5
to python2.1, so python-<module> will have to change to depend on the new
python2.1-<module>, but why does this need to be more than just a <debian-
revision> change?
> 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
> ... ...
>
> - 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.
Correction... which depends on the current "default" version of the versioned
package, which must correspond with the "default" version specified by the
corresponding python-base package. There might be working python2.1 packages
available, but still have python1.5 as the default.
> So we will have at least python-tk, python-gdbm, etc ...
> Same for python-base and python-dev.
Yep.
> 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).
This is optional.
Third party modules have the choice of producing versioned modules with a
default specified by a wrapper package as above, or they can produce a single
un-versioned package that has "Depends: pythonX.Y-base". Note that if they
choose the second option, they are tying their module to a particular version
of python, so any other packages that use this module will also be tied to that
version and must have "Depends: pythonX.Y-base, <thirdparty module>". A sort of
half way option would be to produce multiple versioned packages, but not
provide a default wrapper. This would make any packages that depend on it tied
to a particular version of python, but they would have the option of which
version to tie to.
Note this assumes the module has to be compiled/linked against a particular
version of python. If the module is actually version independant, then you can
use a single package that just has "Depends: python-base", installs itself
into /usr/lib/python/, and symlinks and compiles it's *.py files into all
the /usr/lib/pythonX.Y/ directorys. Obviously this would be much easier for
package developers if python-base provided a script to do this that could be
called in third-party post-inst scripts. This script would also need to be
called every time a new pythonX.Y-base was installed.
> > There aren't really any better scenarios if you can only use 2.1-based
> > modules with python 2.1, and 2.2-based modules with python 2.2. In
> > particular, this is ensured simply by having the right dependencies.
> You
> > could maybe have some scripts that use python2.1 and python2.1
> modules,
> > and others that use python2.2 and python2.2 modules, but then you have
> > to expect scripts to have the version of python they use hardcoded for
> > no good reason, and things start getting pretty ugly.
> >
> > The proposed scheme also allows you to have different versions of
> python
> > and its modules installed concurrently, although scripts from Debian
> > will only ever use the version matching python.deb.
>
> Assume I have installed
> - python-dev (1.5.x), depending on python1.5-dev
> - python-dev (2.1.x), depending on python2.1-dev
Typo? how can you have two python-dev's installed? Did you mean;
- python (1.5.x), depending on python1.5
- python-foo (1.5.x), depending on python1.5-foo, python (>=1.5,<<2.0)
> - 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.
>
> 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). 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].
if python points at python1.5, you must have python (1.5.x) installed. This
means you can't install python-foo because it's dependancies are violated. You
have to install a python (2.1.x) that makes python point at python2.1 before
you can install the new python-foo. You can install python2.1-foo, but you
can't install the new python-foo that makes it the "default" untill you install
a new python that makes python2.1 the default.
This means that all the wrapper packages that establish a default must be
upgraded together, and the dependancies ensure that this happens.
[...]
> 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.
This seems an arbitary limitation... supporting old architectures is not a
hassle because you've already made all those packages. For new modules, there
is never a requirement to back-port to any architecutures older than the one
that the current python package makes the default (unless you want to). The
default python is never going to go backwards.
> 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.
[...]
This last is way too complicated. It will never happen. I cannot concieve of
any way that such a register/unregister mechanism could prevent dependancy type
problems that the versioned packages + wrapper can't handle.
--
ABO: finger [EMAIL PROTECTED] for more information.
