Comment 9 for bug 221007

Thank you very much for your answer.

By "hardcoded" I meant that it is in the binary package's python script, not obviously in the source.

Since the package has python 2.4 in build-depends (and that @PYTHON@ seems to mean preferably python2.4), it necessary happens every time the package is compiled. Anyway, I removed the "hardcoded" word from the changelog, to kill any ambiguity.

Since my experience is quite poor in python packaging, I did had some doubts on the "cleanness" of the patch, and I thank you for pointing that "env python" is bad, I didn't know. However:
- my patch does fix in a reliable way a package that has a _big_ bug that renders it inusable (since Gutsy, if I recall correctly!)
- I frankly don't know much about makefiles and absolutely have not time now to learn. If this is possible to send this perfectly working hack to Intrepid, I can work on a cleaner fix for Intrepid+1
- I think that your idea of modifying the build process seems cleaner because it can be sent to upstream as a patch, but I'm not totally sure notifying upstream has any sense. The build process ensures python 2.4 is there before hardcoding it; it's an Ubuntu (/Debian) problem if you compile with python 2.4 present and then you want to run it without. It's a guess, please tell me if I'm wrong (I mean: if "/usr/python2.4" in a python script is bad by itself).

Anyway, the patch I'm uploading replaces "env python" "python" and removes the "hardcoded" word from the changelog. I really hope this is OK, because a such simple but important bug not fixed along 3 releases would be something quite ridiculous.

If someone else can do now something better, perfect.