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

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

Josselin Mouette wrote:
> Le mardi 04 juillet 2006 à 09:25 +0200, Vincent Danjean a écrit :
>> What would be the interest for an application to be present (compiled)
>> several times on the same system ?
> 
> This is the whole point of the new policy. It allows for several python
> versions to be installed at once.

For a module, yes, but for an application ?

>> By the way, I prepared an update to the new python policy for my 3
>> python packages. You can look at them here :
>> http://dept-info.labri.fr/~danjean/deb.html#commit-tool
> 
> This one doesn't look good. You are explicitly hardcoding python2.3
> which is exactly the wrong thing to do if you want smooth upgrades.

I hardcode python2.3 (and depend on it) so that my package still work
when the python package will provide another default python interpreter.

Note that it is not "python2.3" that I hardcode when building, but
"pyversion -d". So that, when a new default python version will be
uploaded, a simple binary rebuild of my package will make it working
with the new python interpreter.
And my package will not be broken in the time between the upload of
the new python package and the binary rebuild of my package.

Note: It that case, the python program includes binary blobs so it only
works with the same python interpreter used at built time. This is why
using "#!/usr/bin/env python" would lead to breakage when switching the
default python version.

> Also, you have left some autogenerated files as postinst and prerm.

Oups, I will remove them. Thanks.

>> http://dept-info.labri.fr/~danjean/deb.html#mercurial
> 
> I don't understand why you are hardcoding python2.4 in the scripts. Do
> they not work with python2.3 ?

I use cdbs which calls "pythonX.Y setup.py build" in turn for each
supported python versions. I saw a previous thread on this ML telling
that cdbs should end with a build with python (and not pythonX.Y).
My (source) script has "#!/usr/bin/env python". The substitution is
not from me here.

> You are also making complicated things like hand-made symbolic links in
> the python-support directories while dh_pysupport should handle them
> automatically.

I was already doing that before the new policy (to move arch indep files
from /usr/lib to /usr/share where as upstream puts all in /usr/lib)
If dh_pysupport handles that automatically, I will let him doing it :-)

  Best regards,
    Vincent