[HELP] new policy with a compiled python program and generic python plugin module

[Vincent Danjean <Vincent.Danjean@ens-lyon.org>]

  Hi,

  I'm converting one of my package (commit-tool) to the new policy.
I was thinking it will be easy, but I found several difficulties.
I'm able to deal with them so that I will be conformed to the new
policy, but I would like to do the Right Things.

  Here is the situation.
  My package has mainly one program "gct". This is a compiled python
script (ie it begins with #!/usr/bin/python but it has binary blobs few
lines latter).
  It is built from the upstream source (several python source
files) with the help of an upstream program builder (a python script
called buildMain.py).

  It seems that "gct" can be built with any version of python
(python2.3, python2.4, ...), but it must run with the same version
it has been built.

  So, if I build "gct" with the current python version, I have sereral
choice :
A) manually choose a python version and hardcode what is needed:
- replace the first line by "#!/usr/bin/python2.3" and hardcode
  a dependency on python2.3
- (use a build-depend on python2.3 and patch the build system to use
   python2.3) or (use a build-depend on python (>=2.3), python (<<2.4)
   and do not patch the build system)
B) try to use the default python version present at built time
B1) using /usr/bin/python
- let the first line of gct to be "#!/usr/bin/python"
- generate a depend on python (>=current), python (<<current+1)
  [with current replaced with the correct value]
- build-depend on python
B2) using /usr/bin/$(pyversions -d)
- replace the first line of gct with /usr/bin/$(pyversions -d)
- generate a depend on $(pyversions -d)
- build-depend on python
C) other thing I did not think about...

I know how to do A. However, the package will need modifications at each
python transition.

B seems better to me as a simple binary-NMU would generate a package for
the current default python version. It seems to me that B2 is better
than B1 as it is less annoying when a transition occurs (I would welcome
advices/comments on this point).

In any case, can you tell me how I can generate the dependencies for B1
or B2 at built time. Are dh_python{,central,support} able to help me
here ?
  I tried with dh_pythoncentral with "XS-Python-Version: current"
but ${python:Depends} do not expand to what I would like
(not (>=current), python (<<current+1), nor $(pyversions -d))


  And when all of this will be solved, I have another problem :
commit-tool also provide a small python module (hct.py) that will
be a "plugin" for another package (mercurial). hct.py calls gct
as a binary program, so the python version used for hct.py is
independent of the one for gct. As mercurial provides public modules
(used by the tailor program for example), hct.py will need to be
available to any supported python version. So the solution for my
previous problem (generating correct depends for B) must be compatible
with the fact that I also provide a module for any python version.

  So, I would be glad to get help/comments/advices on this, in
particular on the way to generate dependencies for my B (B1 or B2)
proposal.

  Best regards,
    Vincent