Coin Joss, Josselin Mouette <[EMAIL PROTECTED]> writes:
> 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)
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. 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.
--
Marc Dequènes (Duck)
pgpGpZciELjxT.pgp
Description: PGP signature
