On Wed, May 10, 2006 at 08:34:37PM +0200, Marc Dequènes wrote:
> > As Steve suggested, this can be solved by introducing a new variable
> > named ${python:Provides} in dh_python, which will read the .version as
> > well. Then, python-editobj will have a
> > Provides: python2.3-editobj, python2.4-editobj
> > and python2.4-soya will need a
> > Depends: python2.4, python2.4-editobj
> Where my python-ontopofsoya library between soya and slune (i should
> have given it a name) here ? I was probably unclear. The situation
> you're trying to solve seems to me to carry no problem since
> python-editobj will for sure provides all supported python versions
> (python-support magic) and pythonx.y-soya cannot be built if the
> corresponding python version is not in the archive. Soya is currently
> depending on editobj this way without problem, and working with 2.3 and
> 2.4 packages (slune and balazar).
> Let me reexplain the situation i was talking about with a little graph:
> python-editobj (using python-support)
> |
> python2.3-soya (compiled)
> |
> python-ontopofsoya (using python-support)
> |
> slune (using current version)
A package named python-ontopofsoya should not be depending on just
python2.3-soya. It should be depending on python-soya, which can depend on
(or provide) python2.3-soya.
*IFF* python-ontopofsoya Provides: python2.3-ontopofsoya, then it must also
depend on python2.3-soya. If it Provides: python2.4-ontopofsoya, then it
must depend on python2.4-soya. But this is merely an expression of
existing/previous python policy using virtual packages.
> In this example python2.3-soya is required because the slune depends
> on the python package and the current version is 2.3. But since slune
> does not directly depend on soya, and should be unaware of the
> ontopofsoya backend (could possibly use pyopengl for example), and
> python-ontopofsoya cannot arbitrarily choose a soya version, or would
> choose the default one.
python-ontopofsoya *must* depend on python-soya, which must exist as either
a virtual or real package. The python-ontopofsoya and python-soya packages
must also be available in forms that work with the same version of python,
or else python-ontopofsoya is uninstallable (a feature, not a bug).
Likewise, if python-ontopofsoya Provides: python2.3-ontopofsoya,
python2.4-ontopofsoya, then it must also depend on the packages it needs for
*each* version of python it declares support for in order to be useful with
that version.
This scheme is only working if soya has a dummy
> package depending on the current version and slune is using the default
> python. This is true for slune but balazar needs 2.4 and would not be
> able to work. Happily, there is no ontopofsoya module, but this is a
> test case.
If balazar Depends: python2.4, python2.4-ontopofsoya as it should, then
whichever package implements python2.4-ontopofsoya should take care of the
rest. If python-ontopofsoya does not have the proper dependencies to make
its module usable with python2.4, then it should not be declaring that it
Provides: python2.4-ontopofsoya.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature