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. [EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
