Your message dated Tue, 05 Sep 2006 15:40:48 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Bug#385305: commit-tool: please use /usr/bin/python instead of
/usr/bin/$(shell pyversions -d)
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
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.
Please just use /usr/bin/python instead.
It's not stricto sensu a policy violation, but in the spirit it's
suboptimal. the patch is pretty straightforward.
--- End Message ---
--- Begin Message ---
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
--- End Message ---
