Pierre Habouzit a écrit :
> Package: commit-tool
> Severity: important
>
> your build system sets the shebangs to #!/usr/bin/pythonX.Y whereas
> there is no point in doing so, and that breaks the natural upgrades of
> your packages when the default python changes.
There is point of doing so. The upstream maintainer use a kind of build
system so that the /usr/bin/gct binary contains _compiled_ binary code:
[...]
__builtin__.__import__ = MyImport
addModule('mysubprocess', ';\xf2\r\n\xf2\xbf\x9dDc\x00...
[...]
This code is python version dependant (at least, this is not the same
code with python2.3 and python2.4)
If I put /usr/bin/python at the start of the program, it will break when
the python symlink will not be the same version as of one when the
package is built.
With my script, I ensure that:
1) my package is compiled with the current default python
[ie if the current default python is modified, a bin-NMU will update
my package, no source change needed]
2) if the current default python change (as now with the transition
2.3->2.4), my package is still correct (dependency upon and use of
the correct python interpreter for the binary python code used in
the programme.
I think the real good thing would be to convince upstream to use more
standard ways to build, install and run its python program. But until
this happen, I will close this bug report (and trigger a rebuild of the
package so that it use python2.4)
I close this bug, but feel free to reopen it if your are not convinced
by my argument, or if one of theses assertions is false (I do not know
python enough to be sure) :
* python bytecode is specific to one python version
* python bytecode is arch dependent (then the package needs to be
arch: any)
Best regards,
Vincent
