When discussing the "new" python policy at debconf, one of the interesting points that were raised is the need to set explicit dependencies for all virtual python2.X-foo packages you need.
Let's consider the pygtk example: python-gtk2 depends on python-gobject,
and provides python2.4-gtk2. If you rebuild it against python2.5, you
end up providing python2.5-gtk2. However if you install an older version
of python-gobject that doesn't include python2.5 support, the python2.5
interface in python-gtk2 will not work. To avoid that, the new package
must depend on python2.5-gobject.
However there is currently approximately zero package which act this
way, because there is no way to automate that.
As the first python2.5 rebuild tests showed, this is likely to hit us
hard during the 2.4 -> 2.5 transition, and it is going to rain RC bugs.
Therefore, I have implemented a simple mechanism to deal with it in
python-support and uploaded it to experimental. Please note that the
interface is subject to change as long as it isn't in unstable, so this
is only for testing purposes.
In our example, let's say we have:
Package: python-gtk2
Depends: python-gobject (>= 2.12), ${shlibs:Depends}, ${python:Depends}
You can now build-depend on python-support 0.6 and change this to:
Package: python-gtk2
Depends: ${shlibs:Depends}, ${python:Depends}
Python-Depends: python-gobject (>= 2.12)
Then, dh_pysupport will automatically add python-gobject (>= 2.12) and
all needed python2.X-gobject to the ${python:Depends} variable.
It would of course be easier for the user to just parse the Depends:
field, but in this case you can't know if all python-foo packages
depended upon have a correct Provides: field. I'm sure this would break
in some cases.
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.
signature.asc
Description: Ceci est une partie de message numériquement signée
